From huq@rockie.nsc.com Mon Aug 1 11:35:59 1994 Return-Path: Received: from gatekeeper.nsc.com by vhdl.vhdl.org (4.1/SMI-4.1/BARRNet) id AA17365; Mon, 1 Aug 94 11:35:59 PDT Received: from nsc.nsc.com by gatekeeper.nsc.com (5.65/fma-120691) with SMTP; id AA27428 for ibis@vhdl.org; Mon, 1 Aug 94 11:32:46 -0700 Received: from lightning.nsc.com by nsc.nsc.com (5.65/1.34) with SMTP id AA24266 for ibis@vhdl.org; Mon, 1 Aug 94 11:32:44 -0700 Received: from kural by rockie.nsc.com (4.1/SMI-4.1) id AA11163; Mon, 1 Aug 94 11:34:07 PDT Date: Mon, 1 Aug 94 11:34:07 PDT From: huq@rockie.nsc.com (Syed Huq) Message-Id: <9408011834.AA11163@rockie.nsc.com> To: ibis@vhdl.org Subject: Multiple Power pin defination Cc: huq@rockie.nsc.com Hello IBIS gurus: A question for anyone - > I am modeling a RS-232 Driver that uses a Charge pump. So when I apply 5V to Vcc, the internal Charge pump doubles the voltage and creates the V+ = +10V and V- = -10V as required by the Driver. So, in the [Pin] keyword section, I am doing the following: ------------------------------------------------------------- . . [Pin] signal_name model_name . . . . . . 4 VDD POWER | 5V is applied here . . . . . . 5 V+ POWER | +10V for V+ . . . . . . 8 V- POWER | -10V for V- . . . . . . and in the [voltage range] keyword section, I am doing: typ min max [voltage range] 10.0V 9.75V 10.25V | for 10V typ --------------------------------------------------------------- Is my approach correct ? How do I know, that V- pin is getting a -10V supply ? What is the best way to define a +/- POWER ? I am using IBIS v1.1 Regards, Syed huq National Semiconductor. From steffen@anacad.de Mon Aug 1 12:01:11 1994 Return-Path: Received: from mail.Germany.EU.net by vhdl.vhdl.org (4.1/SMI-4.1/BARRNet) id AA17584; Mon, 1 Aug 94 12:01:11 PDT Received: by mail.Germany.EU.net with UUCP (8.6.5:29/EUnetD-2.4.3.g) via EUnet id UAA10439; Mon, 1 Aug 1994 20:59:17 +0200 Received: from asterix.noname anacad.de by anacad.de (4.1/SMC-5.11) Date: Mon, 1 Aug 94 20:31:18 +0200 From: *** Steffen Rochel *** Message-Id: <9408011831.AA06678@anacad.de> To: ibis@vhdl.org path sr@anacad.de send pub/ibis From jrbren@VNET.IBM.COM Mon Aug 1 12:45:45 1994 Return-Path: Received: from VNET.IBM.COM by vhdl.vhdl.org (4.1/SMI-4.1/BARRNet) id AA17824; Mon, 1 Aug 94 12:45:45 PDT Message-Id: <9408011945.AA17824@vhdl.vhdl.org> Received: from BTVLABVM by VNET.IBM.COM (IBM VM SMTP V2R2) with BSMTP id 2143; Mon, 01 Aug 94 15:38:22 EDT Date: Mon, 1 Aug 94 15:42:11 EDT From: "John Brennan (446-6982)" To: IBIS@vhdl.org Subject: IO Files Pared to .ibs Greetings, I am generating a directory of IO circuit data where the directory will contain the data for a given IO(what would be under the [model] keyword). This data will be parsed into a [component] by the chip designer. I want to mark the IO by date, file rev, and ibis version. There are keywords for this at the component level, but if I put these in my IO files, there will be mulitple occurances of these keywords in a .ibs file (1 occurance for each IO). Should I... 1.) leave the keywords in there since IBIS does not care if there are multiple occurances of these keywords. 2.) Comment them out, so the parsers will not see the dates, but they will still show up in the .ibs file as comments. Also, is there any existing software out there that can read the [Pin] keyword model_name, and given directory, go get the ibis data for that file and append to the present file that would contain the [Pin] list? Please advise. Thanks again, John Brennan From huq@rockie.nsc.com Mon Aug 1 14:42:23 1994 Return-Path: Received: from gatekeeper.nsc.com by vhdl.vhdl.org (4.1/SMI-4.1/BARRNet) id AA18769; Mon, 1 Aug 94 14:42:23 PDT Received: from nsc.nsc.com by gatekeeper.nsc.com (5.65/fma-120691) with SMTP; id AA05257 for ibis@vhdl.org; Mon, 1 Aug 94 14:39:10 -0700 Received: from lightning.nsc.com by nsc.nsc.com (5.65/1.34) with SMTP id AA03546 for ibis@vhdl.org; Mon, 1 Aug 94 14:39:03 -0700 Received: from kural by rockie.nsc.com (4.1/SMI-4.1) id AA12564; Mon, 1 Aug 94 14:40:26 PDT Date: Mon, 1 Aug 94 14:40:26 PDT From: huq@rockie.nsc.com (Syed Huq) Message-Id: <9408012140.AA12564@rockie.nsc.com> To: ibis@vhdl.org Subject: Resending:Multiple Power pin defination Resending.. Syed. ----- Begin Included Message ----- From huq Mon Aug 1 11:34:09 1994 Date: Mon, 1 Aug 94 11:34:07 PDT From: huq (Syed Huq) To: ibis@vhdl.org Subject: Multiple Power pin defination Cc: huq Content-Length: 916 Hello IBIS gurus: A question for anyone - > I am modeling a RS-232 Driver that uses a Charge pump. So when I apply 5V to Vcc, the internal Charge pump doubles the voltage and creates the V+ = +10V and V- = -10V as required by the Driver. So, in the [Pin] keyword section, I am doing the following: ------------------------------------------------------------- [Pin] signal_name model_name 1 XXX XXX 2 YYY YYY 3 ZZZ ZZZ 4 VDD POWER | 5V is applied here 5 V+ POWER | +10V for V+ 8 V- POWER | -10V for V- 9 10 and in the [voltage range] keyword section, I am doing: typ min max [voltage range] 10.0V 9.75V 10.25V | for 10V typ --------------------------------------------------------------- Is my approach correct ? How do I know, that V- pin is getting a -10V supply ? What is the best way to define a +/- POWER ? I am using IBIS v1.1 Regards, Syed huq National Semiconductor. ----- End Included Message ----- From mbs@eos.ncsu.edu Mon Aug 1 14:55:16 1994 Return-Path: Received: from mbs.ece.ncsu.edu (c11058-335dan.ece.ncsu.edu) by vhdl.vhdl.org (4.1/SMI-4.1/BARRNet) id AA18947; Mon, 1 Aug 94 14:55:16 PDT Received: by mbs.ece.ncsu.edu (5.65/Eos/C-U-09Sep93) id AA10530; Mon, 1 Aug 1994 17:52:01 -0400 From: mbs@eos.ncsu.edu Message-Id: <9408012152.AA10530@mbs.ece.ncsu.edu> To: ibis@vhdl.org Subject: IBIS parser Date: Mon, 01 Aug 94 17:52:00 EDT John Brennan writes: >I am generating a directory of IO circuit data where the >directory will contain the data for a given IO(what would be >under the [model] keyword). This data will be parsed >into a [component] by the chip designer. I want to mark >the IO by date, file rev, and ibis version. There are keywords for this >at the component level, but if I put these in my IO files, >there will be mulitple occurances of these keywords in a .ibs file >(1 occurance for each IO). Should I... > >1.) leave the keywords in there since IBIS does not care if > there are multiple occurances of these keywords. > >2.) Comment them out, so the parsers will not see the dates, but > they will still show up in the .ibs file as comments. > >Also, is there any existing software out there that can read the >[Pin] keyword model_name, and given directory, go get the ibis data >for that file and append to the present file that would contain the >[Pin] list? I have been thinking along the same lines. I have a yacc/lex parser for IBIS and I have been wondering how to handle libraries and also about the [Disclaimer] [IBIS Ver] [File Rev] [Source] [Notes] [Date] keywords. It appears that it is legal to have more than one of the above keywords. Although the implicit assumption is that there can only be one of each and that they are restricted to the preamble. Having them any where facilitates having include files and having libraries of components constructed at different dates and provided by different vendors. I propose that we handle these keywords in the way that .OPTIONS are handled in Spice. They remain in effect until changed. Then a component becomes the owner of IBIS_VER, SOURCE, MOTES, DATE, FILE_REV and DISCLAIMER data. Also John Brennan's notations can be included in any file including those that are included. Again to facilitate model libraries a [Model] would be treated the same way as a .MODEL in SPICE. To facilitate a valid IBIS file could contain only [Model] statements. In this case the maximum model name will need to be equal to the maximum component name (40). Currently a [Component] is terminated only by another [Component] or by an [End]. To facilitate the different interpretation of [Model] I think that [Component] needs to be viewed as a .SUBCKT . We need an explicit terminator for a [Component] (e.g. [End Component]. Having an explicit terminator is better grammatical practice anyway. Has the IBIS community visited this before? One think that yacc forces you to do is to explicitly state the grammar. Michael Steer From bob@icx.com Mon Aug 1 20:39:50 1994 Return-Path: Received: from uu4.psi.com by vhdl.vhdl.org (4.1/SMI-4.1/BARRNet) id AA20948; Mon, 1 Aug 94 20:39:50 PDT Received: by uu4.psi.com (5.65b/4.0.071791-PSI/PSINet) via UUCP; id AA12869 for ; Mon, 1 Aug 94 23:34:13 -0400 Date: Mon, 1 Aug 94 20:19:53 PDT From: bob@icx.com ( Bob Ross) Received: by icx.com (4.1/3.2.083191-Interconnectix Inc.) id AA12097; Mon, 1 Aug 94 20:19:53 PDT Message-Id: <9408020319.AA12097@icx.com> To: ibis@vhdl.org, jrbren@VNET.IBM.COM Subject: Re: IO Files Pared to .ibs John and IBIS committee In response to your first question with respect to how IBIS currently works, my recommendation is to do choice (2). While some parsers may not care about multiple occurances of certain keywords, other parsers based on ibis_chk will reject some of the multiple occurances you want. Also, there is an explicit statement that [IBIS Ver] be the first keyword encountered. So there is an implicit assumption that all [Models] within a file will be treated at the same [IBIS Ver] level. Even though you want to describe only [Model]s each file will need a [Component] wrapper (even if it is a fictious component) with at least one pin defined (which could be NC and not reference any models within) to pass ibis_chk. I am not aware of any general, non-product-specific software that can pick from [Pin] lists any referenced model from any directory. However, I am aware that equivalent capablility does exist within products through various mechanisms and interfaces. Bob Ross Interconnectix, Inc. > Greetings, > I am generating a directory of IO circuit data where the > directory will contain the data for a given IO(what would be > under the [model] keyword). This data will be parsed > into a [component] by the chip designer. I want to mark > the IO by date, file rev, and ibis version. There are keywords for this > at the component level, but if I put these in my IO files, > there will be mulitple occurances of these keywords in a .ibs file > (1 occurance for each IO). Should I... > 1.) leave the keywords in there since IBIS does not care if > there are multiple occurances of these keywords. > 2.) Comment them out, so the parsers will not see the dates, but > they will still show up in the .ibs file as comments. > Also, is there any existing software out there that can read the > [Pin] keyword model_name, and given directory, go get the ibis data > for that file and append to the present file that would contain the > [Pin] list? > Please advise. > Thanks again, > John Brennan From bob@icx.com Mon Aug 1 21:29:05 1994 Return-Path: Received: from uu4.psi.com by vhdl.vhdl.org (4.1/SMI-4.1/BARRNet) id AA21113; Mon, 1 Aug 94 21:29:05 PDT Received: by uu4.psi.com (5.65b/4.0.071791-PSI/PSINet) via UUCP; id AA17352 for ; Tue, 2 Aug 94 00:19:23 -0400 Date: Mon, 1 Aug 94 21:03:37 PDT From: bob@icx.com ( Bob Ross) Received: by icx.com (4.1/3.2.083191-Interconnectix Inc.) id AA12203; Mon, 1 Aug 94 21:03:37 PDT Message-Id: <9408020403.AA12203@icx.com> To: huq@rockie.nsc.com, ibis@vhdl.org Subject: Re: Resending:Multiple Power pin defination Syed and IBIS committee: You will IBIS Version 2.0 functionality to model RS-232 drivers. The [Pulldown reference] and [Gnd clamp reference] keywords in particular are required to specifiy the pulldown and clamping characteristics that are referenced to -10V. I have attached to your example the keywords. Note, [Voltage range] is still required, but could be omitted if the keywords [Pullup reference] AND [Power clamp reference] which both default to [Voltage range] are also defined. Your application raises some interesting points and potential interaction limitations even in the very robust IBIS Version 2.0. One is that since you have an internal charge pump supply (which happens to have external pin in your example) the correlation of a [model] and external POWER sources available though the optional [Pin mapping] keyword is not directly defined. IBIS cannot show how the 5V VDD relates to the [model] +/- 10V values. Secondly, to comply with the INTENT of the pullup and pulldown table voltage ranges you would need to provide voltages data points at +/- 20V beyond the rails, i.e., extend to +/- 30 V. This is not stated explicitly in the spec. However, if there are clamps at both ends, then I would argue that you could in practice reduce the ranges beyond the rails without any practical effects on any simulator to a reasonable value. Bob Ross, Interconnectix, Inc. > Hello IBIS gurus: > A question for anyone - > > I am modeling a RS-232 Driver that uses a Charge pump. So when I apply > 5V to Vcc, the internal Charge pump doubles the voltage and creates the > V+ = +10V and V- = -10V as required by the Driver. > So, in the [Pin] keyword section, I am doing the following: > ------------------------------------------------------------- > [Pin] signal_name model_name > 1 XXX XXX > 2 YYY YYY > 3 ZZZ ZZZ > 4 VDD POWER | 5V is applied here > 5 V+ POWER | +10V for V+ > 8 V- POWER | -10V for V- > 9 > 10 > and in the [voltage range] keyword section, I am doing: > typ min max > [voltage range] 10.0V 9.75V 10.25V | for 10V typ [Pulldown reference] -10 -9.75 -10.25 [Gnd clamp reference] -10 -9.75 -10.25 > --------------------------------------------------------------- > Is my approach correct ? > How do I know, that V- pin is getting a -10V supply ? > What is the best way to define a +/- POWER ? > I am using IBIS v1.1 > Regards, > Syed huq > National Semiconductor. > ----- End Included Message ----- From Derrick_Duehren@ccm2.jf.intel.com Wed Aug 3 12:45:49 1994 Return-Path: Received: from ormail.intel.com by vhdl.vhdl.org (4.1/SMI-4.1/BARRNet) id AA09666; Wed, 3 Aug 94 12:45:49 PDT Received: from relay.jf.intel.com by ormail.intel.com with smtp (Smail3.1.28.1 #12) id m0qVmCs-000MSEC; Wed, 3 Aug 94 12:42 PDT Received: from ccm.hf.intel.com by relay.jf.intel.com (Smail3.1.28.1 #2) id m0qVmBZ-000tweC; Wed, 3 Aug 94 12:41 PDT Received: by ccm.hf.intel.com (ccmgate 3.0) Wed, 3 Aug 94 12:41:09 PST Date: Wed, 3 Aug 94 12:41:09 PST From: Derrick Duehren Message-Id: <940803124109_3@ccm.hf.intel.com> To: IBIS@vhdl.org Subject: IBIS 8/5/94 Meeting Agenda Text item: Text_1 Bob R., Thanks for the call. I had this all done Monday, but forgot to post it. - Derrick IBIS Open Forum Meeting Agenda for 8/5/94 Bridge: Res: (415) 904-8944 #809164 THIS MEETING IS 1 HOUR ONLY All meetings are 8:00 AM to 10:00 AM PDT (15:00 to 17:00 UTC). When you call into the meeting, ask for the IBIS Open Forum hosted by Will Hobbs and give the reservation number. 8:00 Check-in, Intros, Announcements Hobbs - Intros of new IBIS participants - Review of previous meeting's minutes - Miscellany/announcements/treasurer's report - Opens for new issues - Press updates - New models available 8:20 Progress toward enlisting new IC vendors All Golden Parser, 2.1 Hobbs IBIS Librarian Powell Standards body affiliation Hobbs Spice-to-IBIS converter Ross Pending BIRD 17, Number of Points Ross Pending BIRD 18, [Diff Pin] Parameter Order Ross V_fixture sub-keyword Hobbs 8:55 Wrap-up, next meeting plans Hobbs From Arpad_Muranyi@ccm.fm.intel.com Wed Aug 3 14:41:10 1994 Return-Path: Received: from ormail.intel.com by vhdl.vhdl.org (4.1/SMI-4.1/BARRNet) id AA10320; Wed, 3 Aug 94 14:41:10 PDT Received: from relay.jf.intel.com by ormail.intel.com with smtp (Smail3.1.28.1 #12) id m0qVo0W-000MSbC; Wed, 3 Aug 94 14:37 PDT Received: from ccm.hf.intel.com by relay.jf.intel.com (Smail3.1.28.1 #2) id m0qVnzD-000twfC; Wed, 3 Aug 94 14:36 PDT Received: by ccm.hf.intel.com (ccmgate 3.0) Wed, 3 Aug 94 14:36:30 PST Date: Wed, 3 Aug 94 14:36:30 PST From: Arpad Muranyi Message-Id: <940803143630_2@ccm.hf.intel.com> To: ibis@vhdl.org Cc: Will_Hobbs@ccm2.jf.intel.com, John_M_Keifer@ccm.fm.intel.com Subject: Is BIRD17 alive? Text item: Text_1 Hi IBIS folks, I am not sure what the status of the pending BIRD17 is right now. (Is it dead or alive)? However, along similar lines, I have an of observation regarding the 100 point limit in ver1.1. I would like to have everyone's (especially SPICE people's) opinion on this one. Ver1.1 limits the number of voltage points to 100 in any V/I curve and requires that there should be no NAs in the first and last position in the current tables. The intent of the first part of this rule was to satisfy the 100 data pair limit of the PWL sources in SPICE. However, now that I am working on an automated "Best 100 points" algorythm, I realized that the typ min max curves will need different data point distribution with respect to the voltage axis. I can fill in the gaps with NAs in the current columns, but the 100 VOLTAGE point limit severly restricts the total number of points in the individual current columns. Since the typ min and max tables use three individual PWL sources in SPICE anyway, it would make a lot more sense to reword the rule to say the following: "Each V/I curve must have at least 2, but not more than 100 CURRENT points and any number of NAs can be used as long as they are not the first and last data points." According to this new statement we could do the followings (in this example I pretended as if the maximum current points would be limited 10): [Pulldown] | Voltage I(typ) I(min) I(max) | -5.0V -38.0m -34.0m -45.0m -4.0V -37.0m NA NA -3.0V -36.0m NA NA -2.0V -35.0m NA NA -1.0V -34.0m NA NA -0.9V -33.0m NA NA -0.8V -32.0m NA NA -0.7V -31.0m NA NA -0.6V -30.0m NA NA 0.0V NA 0.0m NA 0.5V NA 10.0m NA 1.0V NA 11.0m NA 1.5V NA 12.0m NA 2.0V NA 13.0m NA 2.5V NA 14.0m NA 3.0V NA 15.0m NA 3.5V NA 16.0m NA 4.0V NA NA 30.0m 4.5V NA NA 31.0m 5.0V NA NA 32.0m 5.5V NA NA 33.0m 6.0V NA NA 34.0m 6.5V NA NA 35.0m 7.0V NA NA 36.0m 7.5V NA NA 37.0m 10.0V 45.0m 40.0m 49.0m | Even though the number of voltage points are 26 in this example, each case (typ min max) has no more than 10 points (10 in the example, 100 in real life), which satisfies the SPICE PWL source requirements, but still allows the best 100 for each individual case. I would have had a very hard time if I had to do this extreme example under the old rules (with 10 voltage points). I would very much like to see this change. Does anyone agree or disagree? Can we turn this into a BIRD? Sincerely Arpad Muranyi Intel Corporation From Will_Hobbs@ccm2.jf.intel.com Wed Aug 3 14:57:05 1994 Return-Path: Received: from ormail.intel.com by vhdl.vhdl.org (4.1/SMI-4.1/BARRNet) id AA10388; Wed, 3 Aug 94 14:57:05 PDT Received: from relay.jf.intel.com by ormail.intel.com with smtp (Smail3.1.28.1 #12) id m0qVoFy-000MSsC; Wed, 3 Aug 94 14:53 PDT Received: from ccm.hf.intel.com by relay.jf.intel.com (Smail3.1.28.1 #2) id m0qVoEf-000twcC; Wed, 3 Aug 94 14:52 PDT Received: by ccm.hf.intel.com (ccmgate 3.0) Wed, 3 Aug 94 14:52:29 PST Date: Wed, 3 Aug 94 14:52:29 PST From: Will Hobbs Message-Id: <940803145229_5@ccm.hf.intel.com> To: Arpad_Muranyi@ccm.fm.intel.com, ibis@vhdl.org Cc: John_M_Keifer@ccm.fm.intel.com Subject: Re: Is BIRD17 alive? Text item: Text_1 Arpad, Birds are alive until voted upon. I know that Bob suggested withdrawing the Bird, but the process requires a vote. So we can vote on it on Friday. Your suggestion is significantly different enough from Bob's that it should be its own Bird, if you don't mind generating it. For now, it's Egg #6. (We skipped a couple when we jumped to Egg 5.3, but then, who's counting? Eggs are unofficial. Will Hi IBIS folks, I am not sure what the status of the pending BIRD17 is right now. (Is it dead or alive)? However, along similar lines, I have an of observation regarding the 100 point limit in ver1.1. I would like to have everyone's (especially SPICE people's) opinion on this one. Ver1.1 limits the number of voltage points to 100 in any V/I curve and requires that there should be no NAs in the first and last position in the current tables. The intent of the first part of this rule was to satisfy the 100 data pair limit of the PWL sources in SPICE. However, now that I am working on an automated "Best 100 points" algorythm, I realized that the typ min max curves will need different data point distribution with respect to the voltage axis. I can fill in the gaps with NAs in the current columns, but the 100 VOLTAGE point limit severly restricts the total number of points in the individual current columns. Since the typ min and max tables use three individual PWL sources in SPICE anyway, it would make a lot more sense to reword the rule to say the following: "Each V/I curve must have at least 2, but not more than 100 CURRENT points and any number of NAs can be used as long as they are not the first and last data points." According to this new statement we could do the followings (in this example I pretended as if the maximum current points would be limited 10): [Pulldown] | Voltage I(typ) I(min) I(max) | -5.0V -38.0m -34.0m -45.0m -4.0V -37.0m NA NA -3.0V -36.0m NA NA -2.0V -35.0m NA NA -1.0V -34.0m NA NA -0.9V -33.0m NA NA -0.8V -32.0m NA NA -0.7V -31.0m NA NA -0.6V -30.0m NA NA 0.0V NA 0.0m NA 0.5V NA 10.0m NA 1.0V NA 11.0m NA 1.5V NA 12.0m NA 2.0V NA 13.0m NA 2.5V NA 14.0m NA 3.0V NA 15.0m NA 3.5V NA 16.0m NA 4.0V NA NA 30.0m 4.5V NA NA 31.0m 5.0V NA NA 32.0m 5.5V NA NA 33.0m 6.0V NA NA 34.0m 6.5V NA NA 35.0m 7.0V NA NA 36.0m 7.5V NA NA 37.0m 10.0V 45.0m 40.0m 49.0m | Even though the number of voltage points are 26 in this example, each case (typ min max) has no more than 10 points (10 in the example, 100 in real life), which satisfies the SPICE PWL source requirements, but still allows the best 100 for each individual case. I would have had a very hard time if I had to do this extreme example under the old rules (with 10 voltage points). I would very much like to see this change. Does anyone agree or disagree? Can we turn this into a BIRD? Sincerely Arpad Muranyi Intel Corporation From cer@Cadence.COM Thu Aug 4 05:37:24 1994 Return-Path: Received: from mailgate.cadence.com by vhdl.vhdl.org (4.1/SMI-4.1/BARRNet) id AA17479; Thu, 4 Aug 94 05:37:24 PDT Received: (from smap@localhost) by mailgate.cadence.com (8.6.8/8.6.8) id FAA14610 for ; Thu, 4 Aug 1994 05:34:09 -0700 Received: from cadence.cadence.com(158.140.18.1) by mailgate.cadence.com via smap (V1.0mjr) id sma014583; Thu Aug 4 05:33:36 1994 Received: from oahu by cadence.Cadence.COM (5.61/3.14) id AA18970; Thu, 4 Aug 94 05:32:06 -0700 Received: by oahu (5.65+/1.5) id AA05906; Thu, 4 Aug 94 08:33:37 -0400 Date: Thu, 4 Aug 94 08:33:37 -0400 From: cer@cadence.com (Chrisopher E. Reid) Message-Id: <9408041233.AA05906@oahu> To: ibis@vhdl.org Subject: 100 Point maximums Hello, On the 100-point VI curve limit, I suggest dropping it altogether. Our simulator has no such limit, and if a device needs 1000 points to adequately describe it behavior, well, why not? Those with limited simulators can easily write routines that select a maximum of 100 points from an arbitrary VI curve. Chris From bob@icx.com Fri Aug 5 16:54:56 1994 Return-Path: Received: from uu4.psi.com by vhdl.vhdl.org (4.1/SMI-4.1/BARRNet) id AA04508; Fri, 5 Aug 94 16:54:56 PDT Received: by uu4.psi.com (5.65b/4.0.071791-PSI/PSINet) via UUCP; id AA18667 for ; Fri, 5 Aug 94 19:42:46 -0400 Date: Fri, 5 Aug 94 11:03:32 PDT From: bob@icx.com ( Bob Ross) Received: by icx.com (4.1/3.2.083191-Interconnectix Inc.) id AA26104; Fri, 5 Aug 94 11:03:32 PDT Message-Id: <9408051803.AA26104@icx.com> To: ibis@vhdl.org Subject: BIRD18.2 IBIS members: BIRD18.2 is revised version which has passed and has a text correction. Bob Ross, Interconnectix, Inc. ***************************************************************************** ***************************************************************************** Buffer Issue Resolution Document (BIRD) BIRD ID#: 18.2 ISSUE TITLE: [Diff Pin] Parameter Order REQUESTOR: Bob Ross, Interconnectix, Inc. DATE SUBMITTED: 20 July 1994 DATE REVISED: 25 July 1984, 5 Aug 1994 DATE ACCEPTED BY IBIS OPEN FORUM: 5 August ****************************************************************************** ****************************************************************************** STATEMENT OF THE ISSUE: There is no statement in the [Diff Pin] specification which specifies the order of the columns, in contrast to specifications for other keywords. ****************************************************************************** STATEMENT OF THE RESOLVED SPECIFICATIONS: The first paragraph of Usage Rules is modified using language similar to that in the [Pin Mapping] keyword to state that the column order is fixed. |============================================================================== | Keyword: [Diff Pin] | Required: No |Description: Associates differential pins, their differential | threshold voltages, and differential timing delays. | Sub-Params: inv_pin, vdiff, tdelay_typ, tdelay_min, tdelay_max |Usage Rules: Enter only differential pin pairs. The first column, | [Diff Pin], contains a non-inverting pin number. The second | column, inv_pin, contains the corresponding inverting pin number | for I/O output. Each pin number must match the pin | numbers declared previously in the [Pin] section of the IBIS | file. The third column, vdiff, contains the specified | output and differential threshold voltage between pins if | the pins are Input or I/O model types. For output only | differential pins, the vdiff entry is 0V. The forth, fifth, | and sixth columns, tdelay_typ, tdelay_min, and tdelay_max, | contain launch delays of the non-inverting pins relative to | the inverting pins. The values can be either polarity. | ****************************************************************************** ANALYSIS PATH/DATA THAT LED TO SPECIFICATION For reference, the original Usage Rule text is presented here: |Usage Rules: Enter only differential pin pairs. The [Diff Pin] column | contains a non-inverting pin number and the inv_pin column | always contains the corresponding inverting pin number for | I/O output. The vdiff column contains the specified | output and differential threshold voltage between pins if | the pins are Input or I/O model types. For output only | differential pins, the vdiff entry is 0V. The tdelay columns | contain launch delays of the non-inverting pins relative to | the inverting pins. The values can be either polarity. The column headers for [Diff Pin] should be listed in the specified order. We missed that point when writing the specification. It should be clarified in IBIS Version 2.1. This restriction should simplify all parsers and should not cause anyone any problems. IBIS Ver. 2.0 specifies that the column headers for [Pin Mapping] must appear in the listed order. The first three column headings of [Pin] must also appear in the listed order, but the last three column headings for L_pin, C_pin and R_pin can appear in any order as long as they are all listed. The order of columns for all keywords which support typ-min-max columns is fixed since no column headers are specified (the specification gives optional comment line headings for clarity). ****************************************************************************** ANY OTHER BACKGROUND INFORMATION ****************************************************************************** From bob@icx.com Fri Aug 5 16:55:01 1994 Return-Path: Received: from uu4.psi.com by vhdl.vhdl.org (4.1/SMI-4.1/BARRNet) id AA04514; Fri, 5 Aug 94 16:55:01 PDT Received: by uu4.psi.com (5.65b/4.0.071791-PSI/PSINet) via UUCP; id AA18738 for ; Fri, 5 Aug 94 19:43:26 -0400 Date: Fri, 5 Aug 94 14:36:38 PDT From: bob@icx.com ( Bob Ross) Received: by icx.com (4.1/3.2.083191-Interconnectix Inc.) id AA26553; Fri, 5 Aug 94 14:36:38 PDT Message-Id: <9408052136.AA26553@icx.com> To: ibis@vhdl.org Subject: BIRD18.2 (RETRANSMISSION) IBIS members: BIRD18.2 is revised version which has passed and has a text correction. Bob Ross, Interconnectix, Inc. ***************************************************************************** ***************************************************************************** Buffer Issue Resolution Document (BIRD) BIRD ID#: 18.2 ISSUE TITLE: [Diff Pin] Parameter Order REQUESTOR: Bob Ross, Interconnectix, Inc. DATE SUBMITTED: 20 July 1994 DATE REVISED: 25 July 1984, 5 Aug 1994 DATE ACCEPTED BY IBIS OPEN FORUM: 5 August 1994 ****************************************************************************** ****************************************************************************** STATEMENT OF THE ISSUE: There is no statement in the [Diff Pin] specification which specifies the order of the columns, in contrast to specifications for other keywords. ****************************************************************************** STATEMENT OF THE RESOLVED SPECIFICATIONS: The first paragraph of Usage Rules is modified using language similar to that in the [Pin Mapping] keyword to state that the column order is fixed. |============================================================================== | Keyword: [Diff Pin] | Required: No |Description: Associates differential pins, their differential | threshold voltages, and differential timing delays. | Sub-Params: inv_pin, vdiff, tdelay_typ, tdelay_min, tdelay_max |Usage Rules: Enter only differential pin pairs. The first column, | [Diff Pin], contains a non-inverting pin number. The second | column, inv_pin, contains the corresponding inverting pin number | for I/O output. Each pin number must match the pin | numbers declared previously in the [Pin] section of the IBIS | file. The third column, vdiff, contains the specified | output and differential threshold voltage between pins if | the pins are Input or I/O model types. For output only | differential pins, the vdiff entry is 0V. The forth, fifth, | and sixth columns, tdelay_typ, tdelay_min, and tdelay_max, | contain launch delays of the non-inverting pins relative to | the inverting pins. The values can be either polarity. | ****************************************************************************** ANALYSIS PATH/DATA THAT LED TO SPECIFICATION For reference, the original Usage Rule text is presented here: |Usage Rules: Enter only differential pin pairs. The [Diff Pin] column | contains a non-inverting pin number and the inv_pin column | always contains the corresponding inverting pin number for | I/O output. The vdiff column contains the specified | output and differential threshold voltage between pins if | the pins are Input or I/O model types. For output only | differential pins, the vdiff entry is 0V. The tdelay columns | contain launch delays of the non-inverting pins relative to | the inverting pins. The values can be either polarity. The column headers for [Diff Pin] should be listed in the specified order. We missed that point when writing the specification. It should be clarified in IBIS Version 2.1. This restriction should simplify all parsers and should not cause anyone any problems. IBIS Ver. 2.0 specifies that the column headers for [Pin Mapping] must appear in the listed order. The first three column headings of [Pin] must also appear in the listed order, but the last three column headings for L_pin, C_pin and R_pin can appear in any order as long as they are all listed. The order of columns for all keywords which support typ-min-max columns is fixed since no column headers are specified (the specification gives optional comment line headings for clarity). ****************************************************************************** ANY OTHER BACKGROUND INFORMATION ****************************************************************************** From huq@rockie.nsc.com Mon Aug 8 12:58:41 1994 Return-Path: Received: from gatekeeper.nsc.com by vhdl.vhdl.org (4.1/SMI-4.1/BARRNet) id AA28343; Mon, 8 Aug 94 12:58:41 PDT Received: from nsc.nsc.com by gatekeeper.nsc.com (5.65/fma-120691) with SMTP; id AA26561 for ibis@vhdl.org; Mon, 8 Aug 94 12:55:23 -0700 Received: from lightning.nsc.com by nsc.nsc.com (5.65/1.34) with SMTP id AA03752 for ibis@vhdl.org; Mon, 8 Aug 94 12:55:21 -0700 Received: from kural by rockie.nsc.com (4.1/SMI-4.1) id AA27669; Mon, 8 Aug 94 12:56:50 PDT Date: Mon, 8 Aug 94 12:56:50 PDT From: huq@rockie.nsc.com (Syed Huq) Message-Id: <9408081956.AA27669@rockie.nsc.com> To: ibis@vhdl.org Subject: ARPA and IBIS Hi, Just a general questions. I am hearing more about ARPA(Advanced Research Project Agency) in our forum meetings. Exactly, how is IBIS and ARPA related. I think ARPA is Govt. related and funds a lot of projects. Are we getting any funding or hope to get any from ARPA.. Regards, Syed huq National Semiconductor. From Will_Hobbs@ccm2.jf.intel.com Mon Aug 8 13:49:53 1994 Return-Path: Received: from ormail.intel.com by vhdl.vhdl.org (4.1/SMI-4.1/BARRNet) id AA28581; Mon, 8 Aug 94 13:49:53 PDT Received: from relay.jf.intel.com by ormail.intel.com with smtp (Smail3.1.28.1 #12) id m0qXbaS-000MRZC; Mon, 8 Aug 94 13:46 PDT Received: from ccm.jf.intel.com by relay.jf.intel.com (Smail3.1.28.1 #2) id m0qXbZ1-000twcC; Mon, 8 Aug 94 13:44 PDT Received: by ccm.jf.intel.com (ccmgate 3.0) Mon, 8 Aug 94 13:44:55 PST Date: Mon, 8 Aug 94 13:44:55 PST From: Will Hobbs Message-Id: <940808134455_3@ccm.jf.intel.com> To: huq@rockie.nsc.com, ibis@vhdl.org Subject: Re: ARPA and IBIS Text item: Syed, North Carolina State U. got ARPA funding to do the Spice to IBIS converter, and the DIE project, I believe, also has some ARPA funding. DIE uses IBIS for the signal integrity part of its spec. Will Hobbs Intel Corp. Hi, Just a general questions. I am hearing more about ARPA(Advanced Research Project Agency) in our forum meetings. Exactly, how is IBIS and ARPA related. I think ARPA is Govt. related and funds a lot of projects. Are we getting any funding or hope to get any from ARPA.. Regards, Syed huq National Semiconductor. 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: ARPA and IBIS To: ibis@vhdl.org Message-Id: <9408081956.AA27669@rockie.nsc.com> From: huq@rockie.nsc.com (Syed Huq) Date: Mon, 8 Aug 94 12:56:50 PDT Received: from kural by rockie.nsc.com (4.1/SMI-4.1) id AA27669; Mon, 8 Aug 94 12:56:50 PDT Received: from lightning.nsc.com by nsc.nsc.com (5.65/1.34) with SMTP id AA03752 for ibis@vhdl.org; Mon, 8 Aug 94 12:55:21 -0700 Received: from nsc.nsc.com by gatekeeper.nsc.com (5.65/fma-120691) with SMTP; id AA26561 for ibis@vhdl.org; Mon, 8 Aug 94 12:55:23 -0700 Received: from gatekeeper.nsc.com by vhdl.vhdl.org (4.1/SMI-4.1/BARRNet) id AA28343; Mon, 8 Aug 94 12:58:41 PDT Received: from vhdl.vhdl.org by hermes.intel.com (5.65/10.0i); Mon, 8 Aug 94 13: Received: from hermes by ichips.intel.com (5.64+/10.0i); Mon, 8 Aug 94 13:07:04 Received: from ichips.intel.com by relay.jf.intel.com with smtp (Smail3.1.28.1 #2) id m0qXaxD-000twcC; Mon, 8 Aug 94 13:05 PDT From Richard_Wright@ccm.fm.intel.com Mon Aug 8 14:07:16 1994 Return-Path: Received: from hermes.intel.com by vhdl.vhdl.org (4.1/SMI-4.1/BARRNet) id AA28666; Mon, 8 Aug 94 14:07:16 PDT Received: from fmmail.fm.intel.com by hermes.intel.com (5.65/10.0i); Mon, 8 Aug 94 14:03:56 -0700 Received: from fmsmt13.intel.com by fmmail.fm.intel.com with SMTP id AA21203 (5.65c/IDA-1.4.4 for ); Mon, 8 Aug 1994 14:02:24 -0700 Received: from cc:Mail by fmsmt13.intel.com id AA776379764; Mon, 08 Aug 94 13:54:16 PST Date: Mon, 08 Aug 94 13:54:16 PST From: "Wright, Richard" Message-Id: <9407087763.AA776379764@fmsmt13.intel.com> To: ibis@vhdl.org Subject: test message Hello, My name is Richard Wright. I work at Intel's internal helpdesk. I am working with Arpad Muranyi because he has received errors while attempting to send to ibis@vhdl.org. He received the error "Your mail to xsft2 is undeliverable". Could you please respond to this test message if you receive it. Thanks for your assistance. Richard Wright INTEL Corp. 916-356-6820 From bob@icx.com Mon Aug 8 16:25:49 1994 Return-Path: Received: from uu4.psi.com by vhdl.vhdl.org (4.1/SMI-4.1/BARRNet) id AA29268; Mon, 8 Aug 94 16:25:49 PDT Received: by uu4.psi.com (5.65b/4.0.071791-PSI/PSINet) via UUCP; id AA21779 for ; Mon, 8 Aug 94 19:05:21 -0400 Date: Mon, 8 Aug 94 15:49:40 PDT From: bob@icx.com ( Bob Ross) Received: by icx.com (4.1/3.2.083191-Interconnectix Inc.) id AA03695; Mon, 8 Aug 94 15:49:40 PDT Message-Id: <9408082249.AA03695@icx.com> To: ibis@vhdl.org Subject: Model Version Supported To IBIS Committee: Regarding the question whether should Version 1.1 level models be designated Version 2.1 when Version 2.1 is stabilized (general opinion at last Fridays meeting was NO), I now feel that BOTH versions should be supported. Version 1.1 provides essential functionality compatible with everyone's parser, but only through a Version 2.1 designation will certain additional, potentially useful capabilties be available, even for Version 1.1 models. One useful addition for all Version 1.1 models consists of the Vmeas, Cref, Rref, Vref test setup. So, I propose that all model producers consider posting, where possible, BOTH Version 1.1 level models and Version 2.1 level models with the IBIS Version 2.1 extensions. This can be done in several ways: (1) Post models in a Ver1.1 directory and also in a Ver2.1 directory, (2) Or possibly, post models at the Lowest level (Ver1.1). but through a defined comment string (e.g. "|#*#") add in the Version 2.1 features which can be easily inserted when the comment string is deleted with a text editor (along with converting to [IBIS_Ver] 2.1). I would favor (1) since tested models of each Version are directly available, but that puts some burden on the Vendor to keep changes to models in Sync in two files. Choice (2) is interesting, especially if there were a standardized comment scheme so a simple script could test and do the conversions AUTOMATICALLY on ANY file. Care would have to be taken to allow any [Comment char], and there may be future, unanticipated compatibility problems regarding possible new features and changes. Comments? Bob Ross, Interconnectix, Inc. From Don_A_Telian@ccm.fm.intel.com Mon Aug 8 17:38:34 1994 Return-Path: Received: from ormail.intel.com by vhdl.vhdl.org (4.1/SMI-4.1/BARRNet) id AA29629; Mon, 8 Aug 94 17:38:34 PDT Received: from relay.jf.intel.com by ormail.intel.com with smtp (Smail3.1.28.1 #12) id m0qXf9d-000MSPC; Mon, 8 Aug 94 17:34 PDT Received: from ccm.hf.intel.com by relay.jf.intel.com (Smail3.1.28.1 #2) id m0qXf8D-000twcC; Mon, 8 Aug 94 17:33 PDT Received: by ccm.hf.intel.com (ccmgate 3.0) Mon, 8 Aug 94 17:33:28 PST Date: Mon, 8 Aug 94 17:33:28 PST From: Don A Telian Message-Id: <940808173328_3@ccm.hf.intel.com> To: bob@icx.com, ibis@vhdl.org Subject: Re: Model Version Supported Text item: Speaking from a group that releases a good number of IBIS models, we would like to release 2.1 models ASAP. However, we do not want to do so too early because many simulators may choke on them (upsetting our customers). I would like to see the IBIS Committee come up with a date, by consensus, when semi. vendors can confidently release 2.1 models. I'll assume this date will be after tool vendors have had time to integrate the 2.1 parser, which sounds to me like January '95? Again, please publish a date ALL of the tool vendors are comfortable with. Thanks, Donald Telian, Intel ______________________________ Reply Separator _________________________________ Subject: Model Version Supported Author: bob@icx.com at Internet_Gateway Date: 8/8/94 4:31 PM To IBIS Committee: Regarding the question whether should Version 1.1 level models be designated Version 2.1 when Version 2.1 is stabilized (general opinion at last Fridays meeting was NO), I now feel that BOTH versions should be supported. Version 1.1 provides essential functionality compatible with everyone's parser, but only through a Version 2.1 designation will certain additional, potentially useful capabilties be available, even for Version 1.1 models. One useful addition for all Version 1.1 models consists of the Vmeas, Cref, Rref, Vref test setup. So, I propose that all model producers consider posting, where possible, BOTH Version 1.1 level models and Version 2.1 level models with the IBIS Version 2.1 extensions. This can be done in several ways: (1) Post models in a Ver1.1 directory and also in a Ver2.1 directory, (2) Or possibly, post models at the Lowest level (Ver1.1). but through a defined comment string (e.g. "|#*#") add in the Version 2.1 features which can be easily inserted when the comment string is deleted with a text editor (along with converting to [IBIS_Ver] 2.1). I would favor (1) since tested models of each Version are directly available, but that puts some burden on the Vendor to keep changes to models in Sync in two files. Choice (2) is interesting, especially if there were a standardized comment scheme so a simple script could test and do the conversions AUTOMATICALLY on ANY file. Care would have to be taken to allow any [Comment char], and there may be future, unanticipated compatibility problems regarding possible new features and changes. Comments? Bob Ross, Interconnectix, Inc. 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: Model Version Supported To: ibis@vhdl.org Message-Id: <9408082249.AA03695@icx.com> Received: by icx.com (4.1/3.2.083191-Interconnectix Inc.) id AA03695; Mon, 8 Aug 94 15:49:40 PDT From: bob@icx.com ( Bob Ross) Date: Mon, 8 Aug 94 15:49:40 PDT Received: by uu4.psi.com (5.65b/4.0.071791-PSI/PSINet) via UUCP; id AA21779 for ; Mon, 8 Aug 94 19:05:21 -0400 Received: from uu4.psi.com by vhdl.vhdl.org (4.1/SMI-4.1/BARRNet) id AA29268; Mon, 8 Aug 94 16:25:49 PDT Received: from vhdl.vhdl.org by hermes.intel.com (5.65/10.0i); Mon, 8 Aug 94 16: Received: from hermes.intel.com by relay.jf.intel.com with smtp (Smail3.1.28.1 #2) id m0qXeA7-000twcC; Mon, 8 Aug 94 16:31 PDT From randyh@Synopsys.COM Mon Aug 8 17:57:10 1994 Return-Path: Received: from chronos.synopsys.com by vhdl.vhdl.org (4.1/SMI-4.1/BARRNet) id AA29686; Mon, 8 Aug 94 17:57:10 PDT Received: from gaea.synopsys.com by chronos.synopsys.com with SMTP id AA19658 (5.65c/IDA-1.4.4 for ); Mon, 8 Aug 1994 17:53:44 -0700 Received: from clotho (clotho.synopsys.com) by gaea.synopsys.com with SMTP id AA29018 (5.65c/IDA-1.4.4); Mon, 8 Aug 1994 17:53:43 -0700 Received: from tonga.synopsys.com (tonga.synopsys.com [146.225.82.16]) by clotho (8.6.9/8.6.9) with SMTP id RAA26856; Mon, 8 Aug 1994 17:53:41 -0700 Date: Mon, 8 Aug 1994 17:53:41 -0700 Message-Id: <199408090053.RAA26856@clotho> X-Sender: randyh@engr.synopsys.com Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii" To: huq@rockie.nsc.com (Syed Huq) From: randyh@Synopsys.COM (Randolph E. "Randy" Harr) Subject: Re: ARPA and IBIS Cc: ibis@vhdl.org X-Mailer: ARPA is part of the DoD Research and Engineering office. They are primarly responsible for funding advanced technology development. ARPA spends $2.5 billion a year on such things as HDTV, Flat Panels, MEMS (those neat IC's that are both electrical and mechanical), etc. Many people remember them for funding the initial development of the ARPAnet, TCP/IP and similar work. This has been the basis for the Internet and other recent "hype" about the information superhighway. ARPA also manages the Technology Reinvestment Project (TRP) which is the funnel for much of the "dual-use" "defense conversion" funding. The newly emerging counterpart to them on the commercial side is NIST with their Advanced Technology Program (ATP). Under the Application Specific Electronic Module (ASEM) program, ARPA is funding Logic Modeling to develop "a standard for the interchange of information on Bare Die". Part of our overall information transfer is the technology of signal integrity models. Given IBIS came about as an industry effort, we were able to drop resources in developing this technology and focus it elsewhere. But IBIS is still very important to our effort. Therefore, we are willing to apply resources to assist your goals in order to improve the overall quality of our work. ARPA is also funding NCState on the SPICE2IBIS work. You might check your paycheck also. I am not sure which group you are in at National but National is a major recipient of government funds in general and ARPA in specific. ASEM is also funding much of National's forray into Known Good Die (KGD), MCM's and similar areas. As for whether IBIS gets any funds -- ARPA funds projects in Universities and companies that are presented to them under BAA's or other program announcements. If a company working on the IBIS effort wishes to propose a project, and it is in-line with the goals of a program, then funding is very possible. You always here the commercial the Marines put out -- looking for a few good men. Well ARPA is always looking for a few (thousand) good ideas to fund! >Hi, > >Just a general questions. I am hearing more about ARPA(Advanced Research Project >Agency) in our forum meetings. Exactly, how is IBIS and ARPA related. > >I think ARPA is Govt. related and funds a lot of projects. Are we getting any >funding or hope to get any from ARPA.. > >Regards, >Syed huq >National Semiconductor. > > > Randolph E. (randy) Harr Senior Scientist and Program Manager Logic Modeling Group, Synopsys Inc. randyh@synopsys.com, (415) 694-1835 (voice) From uunet!qdt.com!jonp@uunet.uu.net Tue Aug 9 14:39:13 1994 Return-Path: Received: from relay3.UU.NET by vhdl.vhdl.org (4.1/SMI-4.1/BARRNet) id AA09147; Tue, 9 Aug 94 14:39:13 PDT Received: from uucp4.UU.NET by relay3.UU.NET with SMTP id QQxcgk18424; Tue, 9 Aug 1994 17:34:10 -0400 Received: from qdt.UUCP by uucp4.UU.NET with UUCP/RMAIL ; Tue, 9 Aug 1994 17:34:01 -0400 Received: from hal.qdt.com by qdt.com (4.1/SMI-4.1) id AA00411; Tue, 9 Aug 94 14:31:09 PDT Received: from qdt.com by hal.qdt.com (4.1/SMI-4.1) id AA10400; Tue, 9 Aug 94 14:28:31 PDT Received: from uucp7.UU.NET by relay3.UU.NET with SMTP id QQxcgi16312; Tue, 9 Aug 1994 17:11:40 -0400 Received: from qdt.UUCP by uucp7.UU.NET with UUCP/RMAIL ; Tue, 9 Aug 1994 17:11:51 -0400 Received: from hal.qdt.com by qdt.com (4.1/SMI-4.1) id AA00979; Tue, 9 Aug 94 12:52:18 PDT Received: from f14.qdt.com by hal.qdt.com (4.1/SMI-4.1) id AA09985; Tue, 9 Aug 94 12:49:40 PDT Date: Tue, 9 Aug 94 12:49:40 PDT From: uunet!qdt.com!jonp@uunet.uu.net (Jon Powell) Message-Id: <9408091949.AA09985@hal.qdt.com> Received: by f14.qdt.com (4.1/SMI-4.1) id AA03369; Tue, 9 Aug 94 12:49:29 PDT To: uunet!uunet!ccm.fm.intel.com!Don_A_Telian@uunet.uu.net Cc: uunet!uunet!icx.com!bob@uunet.uu.net, uunet!uunet!vhdl.org!ibis@uunet.uu.net In-Reply-To: Don A Telian's message of Mon, 8 Aug 94 17:33:28 PST <940808173328_3@ccm.hf.intel.com> Subject: Model Version Supported Jan 95 is a reasonable date for Quad. Not to say we won't have it sooner but we can guarantee jan. jonp From Will_Hobbs@ccm2.jf.intel.com Tue Aug 9 16:40:31 1994 Return-Path: Received: from ormail.intel.com by vhdl.vhdl.org (4.1/SMI-4.1/BARRNet) id AA09696; Tue, 9 Aug 94 16:40:31 PDT Received: from relay.jf.intel.com by ormail.intel.com with smtp (Smail3.1.28.1 #12) id m0qY0jE-000MSWC; Tue, 9 Aug 94 16:37 PDT Received: from ccm.jf.intel.com by relay.jf.intel.com (Smail3.1.28.1 #2) id m0qY0hm-000twdC; Tue, 9 Aug 94 16:35 PDT Received: by ccm.jf.intel.com (ccmgate 3.0) Tue, 9 Aug 94 16:35:38 PST Date: Tue, 9 Aug 94 16:35:38 PST From: Will Hobbs Message-Id: <940809163538_5@ccm.jf.intel.com> To: ibis@vhdl.org Subject: re: BIRD 19 ---------------------------- Forwarded with Changes --------------------------- From: bob@icx.com at SMTPGATE Date: 8/8/94 9:00PM To: Will Hobbs at JFCCM2 *To: Stephen Peters *To: Derrick_Duehren@ccm.jf.intel.com at SMTPGATE Subject: BIRD XXX V_fixture and Vref min/max ------------------------------------------------------------------------------- Text item: The mail I sent out with the subject line BIRD XXX, etc., should have said BIRD 19: V_fixture and Vref min/max. I changed the subject line before addressing the BIRD 19. cc:Mail changed the subject back after I addressed it. Don't you love computers making changes for you? Will 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: BIRD XXX V_fixture and Vref min/max To: Derrick_Duehren@ccm.jf.intel.com, Will_Hobbs@ccm2.jf.intel.com, speters@ichips.intel.com Message-Id: <9408090335.AA04656@icx.com> Received: by icx.com (4.1/3.2.083191-Interconnectix Inc.) id AA04656; Mon, 8 Aug 94 20:35:14 PDT From: bob@icx.com ( Bob Ross) Date: Mon, 8 Aug 94 20:35:14 PDT Received: by uu4.psi.com (5.65b/4.0.071791-PSI/PSINet) via UUCP; id AA17251 for ; Mon, 8 Aug 94 23:49:56 -0400 Received: from uu4.psi.com by hermes.intel.com (5.65/10.0i); Mon, 8 Aug 94 21:01 Received: from hermes by ichips.intel.com (5.64+/10.0i); Mon, 8 Aug 94 21:01:33 Received: from ichips.intel.com by relay.jf.intel.com with smtp (Smail3.1.28.1 #2) id m0qXiMT-000twdC; Mon, 8 Aug 94 21:00 PDT From Will_Hobbs@ccm2.jf.intel.com Tue Aug 9 16:40:38 1994 Return-Path: Received: from ormail.intel.com by vhdl.vhdl.org (4.1/SMI-4.1/BARRNet) id AA09700; Tue, 9 Aug 94 16:40:38 PDT Received: from relay.jf.intel.com by ormail.intel.com with smtp (Smail3.1.28.1 #12) id m0qY0jA-000MSOC; Tue, 9 Aug 94 16:37 PDT Received: from ccm.jf.intel.com by relay.jf.intel.com (Smail3.1.28.1 #2) id m0qY0hV-000twdC; Tue, 9 Aug 94 16:35 PDT Received: by ccm.jf.intel.com (ccmgate 3.0) Tue, 9 Aug 94 16:35:19 PST Date: Tue, 9 Aug 94 16:35:19 PST From: Will Hobbs Message-Id: <940809163519_2@ccm.jf.intel.com> To: ibis@vhdl.org, bob@icx.com, Derrick_Duehren@ccm.jf.intel.com, speters@ichips.intel.com Subject: Re: BIRD XXX V_fixture and Vref min/max Text item: IBIS Members: The following BIRD is one approach at addressing the problem John Brennan raised concerning V_fixture voltage changes with supply changes for [Rising waveform] and [Falling waveform] specifications. The same problem can arise for the Vref sub-parameter in the [Model] keyword. Thus the proposed additions to sub-parameters are presented in one BIRD. Bob Ross, Interconnectix, Inc. ***************************************************************************** ***************************************************************************** Buffer Issue Resolution Document (BIRD) BIRD ID#: 19 ISSUE TITLE: V_fixture and Vref Subparameter Min/Max Additions REQUESTOR: Bob Ross, Interconnectix, Inc. DATE SUBMITTED: 8 August 1994 DATE REVISED: DATE ACCEPTED BY IBIS OPEN FORUM: Pending ****************************************************************************** ****************************************************************************** STATEMENT OF THE ISSUE: There are cases with respect to certain devices including CMOS logic where the [Rising Waveform] and [Falling Waveform] fixture load specifications are not adequate to define the min and max table loads. Additional sub- parameters for [Rising Waveform] and [Falling Waveform] are proposed: V_fixture_min and V_fixture_max. A similar situation may occur in the [Model] specification with respect to Vref. If the Model_type is Open_drain, the Vref (or Thevenin equivalent) may be related directly or through some proportion to Vcc and not be fixed. Vref_min and Vref_max are proposed as additonal subparameters. ****************************************************************************** STATEMENT OF THE RESOLVED SPECIFICATIONS: The complete [Model] keyword description is presented here. Changes in the text related to adding "Vref_min" and "Vref_max" are designated by "|*". |============================================================================== | Keyword: [Model] | Required: Yes | Description: Used to define a model, and its attributes. | Sub-Params: Model_type, Polarity, Enable, Vinl, Vinh, C_comp, Vmeas, Cref, |* Rref, Vref, Vref_min, Vref_max | Usage Rules: Each model type must begin with the keyword [Model]. | The model name must match the one that is listed under | the [Pin] keyword and must not contain more than 20 characters. | A .ibs file must contain enough [Model] keywords to cover all | of the model names specified under the [Pin] keyword, except | for those model names that use reserved words (POWER, GND and | NC). Model names with reserved words are an exception and they | do not have to have a corresponding [Model] keyword. | | Model_type must be one of the following: | Input, Output, I/O, 3-state, Open_drain, I/O_open_drain, | Open_sink, I/O_open_sink, Open_source, I/O_open_source, | Input_ECL, Output_ECL, I/O_ECL, and Terminator. | | Special usage rules apply to the following. Some definitions | are included for clarification: | | Input These model types must have Vinl and Vinh | I/O defined. If they are not defined, the | I/O_open_drain parser issues a warning and the default | I/O_open_sink values of Vinl=0.8V and Vinh=2.0V are | I/O_open_source assumed. | | Input_ECL These model types must have Vinl and Vinh | I/O_ECL defined. If they are not defined, the | parser issues a warning and the default | values of Vinl=-1.475V and Vinh=-1.165V | are assumed. | | Terminator This model type is an input-only device that | can have analog loading effects on the | circuit being simulated but has no digital | logic thresholds. Examples of Terminators | are: capacitors, termination diodes, and | pull-up resistors. | | Output This model type indicates that an output | always sources and/or sinks current and | cannot be disabled. | | 3-State This model type indicates that an output | can be disabled, i.e. put into a high | impedance state. | | Open_sink These model type indicate that the output | Open_drain has an OPEN side (do not use the [Pullup] | keyword, or if it must be used, set I = 0mA | for all voltages specified) and the output | SINKS current. Open_drain model type is | retained for backward compatibility. | | Open_source This model type indicates that the | output has an OPEN side (do not use the | [Pulldown] keyword, or if it must be used, | set I = 0mA for all voltages specified) and | the output SOURCES current. | | Input_ECL These model types specify that the model | Output_ECL represents an ECL type logic that follows | I/O_ECL different conventions for the [Pulldown] | keyword. | | The Model_type and C_comp sub-parameters are required. The |* Polarity, Enable, Vinl, Vinh, Vmeas, Cref, Rref, Vref, |* Vref_min, and Vref_max sub- | parameters are optional. C_comp defines the silicon die | capacitance. This value should not include the capacitance of | the package. C_comp is allowed to use "NA" for the min and max | values only. The Polarity sub-parameter can be defined as | either as Non-inverting or Inverting, and the Enable sub- | parameter can be defined as either Active-high or Active-low. | |* The Cref, Rref, Vref, Vref_min, and Vref_max sub-parameters |* correspond to the test load | that the manufacturer uses when specifying the propagation | delay and/or output switching time of the device. The Vmeas | sub-parameter is the reference voltage level that the |* manufacturer uses for the component. Include Cref, Rref, |* Vref and | Vmeas information to facilitate board-level timing simulation. | The assumed connections for Cref, Rref, and Vref are shown in | the following diagram: | | _________ | | | | | |\ | Rref | |Driver| \|------o----/\/\/\----o Vref | | | /| | | | |/ | === Cref | |_________| | | | | GND |* |* Vref defines the test load voltage for typ, min and max |* supply conditions. However, when the test load voltage |* is related to the power supply voltages, then the sub- |* parameters Vref_min and Vref_max can be used to further |* specify the test load conditions for min and max supply |* voltages. | | Other Notes: A complete [Model] description normally contains the following | keywords: [Voltage Range], [Pullup], [Pulldown], [GND Clamp], | [POWER Clamp], and [Ramp]. A Terminator model uses one | or more of the [Rgnd], [Rpower], [Rac], and [Cac]. However, | some models may have only a subset of these keywords. For | example, an input structure normally only needs the | [Voltage Range], [GND Clamp], and possibly the [POWER Clamp] | keywords. If one or more of [Rgnd], [Rpower], [Rac], and [Cac] | keywords are used, then the Model_type must be Terminator. |------------------------------------------------------------------------------ | Signals CLK1, CLK2,... | Optional signal list, if desired [Model] Clockbuffer Model_type I/O Polarity Non-Inverting Enable Active-High Vinl = 0.8V | input logic "low" DC voltage, if any Vinh = 2.0V | input logic "high" DC voltage, if any Vmeas = 1.5V |Reference voltage for timing measurements Cref = 50pF |Timing specification test load capacitance value Rref = 500 |Timing specification test load resistance value Vref = 0 |Timing specification test load voltage |* Vref_min = 0 |Redundant, presented for syntax illustration |* Vref_max = 0 |Redundant, presented for syntax illustration | variable typ min max C_comp 12.0pF 10.0pF 15.0pF | |============================================================================== The [Rising Waveform], [Falling Waveform] keyword description is presented along with changes in the text related to including the sub-parameters "V_fixture_min" and "V_fixture_max". Changed lines are designated by "|*". |============================================================================== | Keywords: [Rising Waveform], [Falling Waveform] | Required: No | Description: Describes the shape of the rising and falling edge | waveforms of a driver. |* Sub-Params: R_fixture, V_fixture, V_fixture_min, V_fixture_max, |* C_fixture, L_fixture, | R_dut, L_dut, C_dut | Usage Rules: Each [Rising Waveform] and [Falling Waveform] keyword | introduces a table of time vs. voltage points that | describe the shape of an output waveform. These | time/voltage points are taken under the conditions | specified in the R/L/C/V_fixture and R/L/C_dut | sub-parameters. The table itself consists of | one column of time points, then three columns of | voltage points in the standard typ, min, and max format. | The four entries must be placed on a single line and | must be separated by at least one white space or tab | character. All four columns are required. However, data | is only required in the typical column. If minimum | or maximum data is not available, use the reserved word | "NA". The first value in the time column need not be '0'. | Time values must increase as one parses down the table. | The waveform table can contain a maximum of 100 data | points. A maximum of 100 waveform tables are allowed per | model. Note that for backwards compatibility, the existing | [Ramp] keyword is still required. | | A waveform table must include the entire waveform; | i.e., the first entry (or entries) in a voltage column | must be the DC voltage of the output before switching | and the last entry (or entries) of the column must be | the final DC value of the output after switching. | | A [Model] specification can contain more than one rising | edge or falling edge waveform table. However, each new | table must begin with the appropriate keyword and sub- | parameter list as shown below. If more than one rising or | falling edge waveform table is present, then the data in | each of the respective tables must be time correlated. | In other words, the rising (falling) edge data in each | of the rising (falling) edge waveform tables must be | entered with respect to a common reference point on the | input stimulus waveform. | | The 'fixture' sub-parameters specifies the loading | conditions under which the waveform is taken. The R_dut, | C_dut, and L_dut Sub-params are analogous to the | package parameters R_pkg, C_pkg and L_pkg and are used | if the waveform includes the effects of pin | inductance/capacitance. The diagram below shows the | interconnection of these elements. | | PACKAGE | TEST FIXTURE | _________ | | | DUT | L_dut R_dut | L_fixture R_fixture | | die |---@@@@@--/\/\/\--o-----|--@@@@---o---/\/\/\----- V_fixture | |_________| | | | | | | | | | | | | C_dut === | === C_fixture | | | | | | | | | GND | GND | | Only the R_fixture and V_fixture sub-parameters are | required, the rest of the sub-parameters are optional. | If a sub-parameter is not used, its value defaults to | zero. The sub-parameters must appear in the text after | the keyword and before the first row of the waveform | table. | |* V_fixture defines the voltage for typ, min and max |* supply conditions. However, when the fixture voltage |* is related to the power supply voltages, then the |* sub-parameters V_fixture_min and V_fixture_max can |* be used to further specify the fixture voltage for |* min and max supply voltages. |* |------------------------------------------------------------------------------ [Rising Waveform] R_fixture = 500 V_fixture = 5.0 |* V_fixture_min = 4.5 |Note, R_fixture is connected to Vcc |* V_fixture_max = 5.5 |Specified, but not used in this example C_fixture = 50p L_fixture = 2n C_dut = 7p R_dut = 1m L_dut = 1n |Time V(typ) V(min) V(max) 0.0ns 0.3 0.5 NA 0.5ns 0.3 0.5 NA 1.0ns 0.6 0.7 NA 1.5ns 0.9 0.9 NA 2.0ns 1.5 1.3 NA 2.5ns 2.1 1.7 NA 3.0ns 3.0 2.7 NA 3.5ns 3.2 3.0 NA | [Falling Waveform] R_fixture = 50 V_fixture = 0 |Time V(typ) V(min) V(max) 10.0ns 3.2 3.0 NA 10.5ns 3.0 2.7 NA 11.0ns 2.1 1.7 NA 11.5ns 1.5 1.3 NA 12.0ns 0.9 0.9 NA 12.5ns 0.6 0.7 NA 13.0ns 0.3 0.5 NA 13.5ns 0.3 0.5 NA | |============================================================================= ****************************************************************************** ANALYSIS PATH/DATA THAT LED TO SPECIFICATION John Brennan writes 7/29/94, "I have a question on the V_fixture ibis sub-keyword for [Falling Waveform]. This variable appears to expect 1 value, ie, typically the nominal power supply value. Since I use the same deck to measure [Ramp] as [Falling Waveform], my deck has the load resistor hooked to the power supply, which will be different for typ, min and max." "Does this present a problem to the simulation vendor that V_fixture cannot handle a min and max value, or If I enter three values will they be handled correctly. Should I change my deck so the the load resistor is hooked to the nominal supply value and not vary it for min and max?" "How important is V_fixture? Also, are the values in the example in spec ver2.0 backwards? Wouldn't a [Falling Waveform] be pulling against a logic "1" voltage, and a [Rising waveform] be pulling against a GND type voltage?" Bob Ross responds 7/29/94, "My initial response is that you uncovered a valid condition which we did not consider fully. We should have allowed a V_fixture_min, and V_fixture_max for cases where the fixture is tied to Vcc or for cases where it represents the Thevenin voltage (and can change). The same will apply for the [Model] subparameter Vref. It may need a Vref_min and Vref_max also. This should be the subject for further consideration and probably a BIRD." An alternative approach would be to redefine V_fixture and Vref similar to the C_comp subparameter on one line in the typ_min_max format. This was not chosen because it could create an unnecessary enlargement of IBIS Version 2.1 to be compatible with IBIS Version 2.0 and also because the additional sub-parameters introduced here may be used less frequently. For completeness, V_fixture_typ and Vref_typ could also have been introduced. However, with the current definition, these are redundant. ****************************************************************************** ANY OTHER BACKGROUND INFORMATION As additional information, a similar problem was encountered in specifying the input waveform amplitudes for the s2ibis program under min and max supply conditions. This is particularly applicable for CMOS logic where a typical voltage range is from 0V to 5V. However, if the supply voltage is at min (say 4.5V), one would expect the Input voltage range to be from 0V to 4.5V). The default condition for s2ibis for IBIS Version 1.1 is to adjust the Input Voltage directly proportional to Vcc. So for a typical TTL Input specification, the Input voltage specified from 0V to 3V is actually 0V to 3V for typ, 0V to 2.5V for min, and 0V to 3.5V for max for a +/- .5V Vcc change. This default condition (which defines the SPICE PULSE command) can be overridden (along with the default Input ramp rise and fall times of .1ns) under each condition by optional specifications: **Input_Ramp_min **Input_ramp_typ **Input_ramp_max So with these specifications, the Input ramp specification can be set to a fixed voltage range such as 0V to 3V for typ-min-max extractions. ****************************************************************************** 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: BIRD XXX V_fixture and Vref min/max To: Derrick_Duehren@ccm.jf.intel.com, Will_Hobbs@ccm2.jf.intel.com, speters@ichips.intel.com Message-Id: <9408090335.AA04656@icx.com> Received: by icx.com (4.1/3.2.083191-Interconnectix Inc.) id AA04656; Mon, 8 Aug 94 20:35:14 PDT From: bob@icx.com ( Bob Ross) Date: Mon, 8 Aug 94 20:35:14 PDT Received: by uu4.psi.com (5.65b/4.0.071791-PSI/PSINet) via UUCP; id AA17251 for ; Mon, 8 Aug 94 23:49:56 -0400 Received: from uu4.psi.com by hermes.intel.com (5.65/10.0i); Mon, 8 Aug 94 21:01 Received: from hermes by ichips.intel.com (5.64+/10.0i); Mon, 8 Aug 94 21:01:33 Received: from ichips.intel.com by relay.jf.intel.com with smtp (Smail3.1.28.1 #2) id m0qXiMT-000twdC; Mon, 8 Aug 94 21:00 PDT From slipa@eos.ncsu.edu Wed Aug 10 11:30:57 1994 Return-Path: Received: from rand.ece.ncsu.edu (c11046-336dan.ece.ncsu.edu) by vhdl.vhdl.org (4.1/SMI-4.1/BARRNet) id AA18433; Wed, 10 Aug 94 11:30:57 PDT Received: by rand.ece.ncsu.edu (5.65/Eos/C-U-09Sep93) id AA11307; Wed, 10 Aug 1994 14:27:35 -0400 From: slipa@eos.ncsu.edu Message-Id: <9408101827.AA11307@rand.ece.ncsu.edu> To: ibis@vhdl.org Subject: s2ibis SPICE-to-IBIS convertor Date: Wed, 10 Aug 94 14:27:33 EDT Dear Ibis Community: Please be aware that Derrick has loaded an updated version of s2ibis into the directory /pub/s2ibis at the vhdl.org ftp site. This version incorporates many changes. Source code is also included. Please give it a try. There are two main files: /pub/s2ibis/S2IBIS10.tar.Z for unix systems and S2IBIS.zip for IBM PC users. Steve Lipa slipa@eos.ncsu.edu PS: Please note that I will be out of the office for about a week, so if you send me EMAIL about the package I will not be able to respond until I get back. From speters@ichips.intel.com Wed Aug 10 13:14:07 1994 Return-Path: Received: from hermes.intel.com by vhdl.vhdl.org (4.1/SMI-4.1/BARRNet) id AA18936; Wed, 10 Aug 94 13:14:07 PDT Received: from [134.134.50.200] by hermes.intel.com (5.65/10.0i); Wed, 10 Aug 94 13:10:42 -0700 Received: from xtg801 by ichips.intel.com (5.64+/10.0i); Wed, 10 Aug 94 13:09:51 -0700 Received: from localhost by xtg801.intel.com (4.1/10.0i); Wed, 10 Aug 94 13:10:38 PDT Message-Id: <9408102010.AA14680@xtg801.intel.com> To: ibis@vhdl.org Subject: BIRD 19 (v_fixture and v_ref subparameters) Date: Wed, 10 Aug 1994 13:10:37 -0700 From: Stephen Peters Hello all: I just got back from vacation today when I read John's Brennan's email regarding varying the v_fixture voltage and Bob's BIRD 19. My thinking when composing the original bird was that each time the v_fixture (or r_fixture, etc.) changed it would constitute different loading conditions and a new waveform table would be needed. However, in thinking about John's specific example I can see why this bird is needed. Im not so sure about creating a V_ref_min and Vref_max parameter though -- do manufactures really change the v_ref voltage when specifing prop delay? Just asking.... Best Regards, Stephen Peters Intel Corp. From jrbren@VNET.IBM.COM Wed Aug 10 13:37:07 1994 Return-Path: Received: from VNET.IBM.COM by vhdl.vhdl.org (4.1/SMI-4.1/BARRNet) id AA19067; Wed, 10 Aug 94 13:37:07 PDT Message-Id: <9408102037.AA19067@vhdl.vhdl.org> Received: from BTVLABVM by VNET.IBM.COM (IBM VM SMTP V2R2) with BSMTP id 1390; Wed, 10 Aug 94 16:34:17 EDT Date: Wed, 10 Aug 94 16:16:13 EDT From: "John Brennan (446-6982)" To: ibis@vhdl.org Subject: BIRD 19 Greetings, Thanks to all who have considered the V_fixture issue. I have changed the connection on the load in my simulation decks so that the thevenin load voltage is the nominal power supply and not Vdd(which varies from typ,min and max conditions). Now V_fixture with one value is a correct represen tation of what I simulated. The question seems to me is whether the buffer char acteristics are being modeled completely by keeping V_fixture the same. If they are, then I would not want to increase complexity of IBIS by adding addiitonal terms. If not, then BIRD 19 should be required. I am not aware of any characteristics that are not being modeled with V_fixture having only one value. Any thoughts? Thanks again, John Brennan From jrbren@VNET.IBM.COM Wed Aug 10 13:44:44 1994 Return-Path: Received: from VNET.IBM.COM by vhdl.vhdl.org (4.1/SMI-4.1/BARRNet) id AA19092; Wed, 10 Aug 94 13:44:44 PDT Message-Id: <9408102044.AA19092@vhdl.vhdl.org> Received: from BTVLABVM by VNET.IBM.COM (IBM VM SMTP V2R2) with BSMTP id 1471; Wed, 10 Aug 94 16:41:54 EDT Date: Wed, 10 Aug 94 16:36:36 EDT From: "John Brennan (446-6982)" To: ibis@vhdl.org Subject: S2IBIS Greetings, I could not load s2ibis10.tar.Z due to insufficient access. If I read the previous note correctly this should be public now? All users do not have read authority yet. s2ibis.zip has general read access. Thanks again, John Brennan From randyh@Synopsys.COM Wed Aug 10 14:43:51 1994 Return-Path: Received: from chronos.synopsys.com by vhdl.vhdl.org (4.1/SMI-4.1/BARRNet) id AA19959; Wed, 10 Aug 94 14:43:51 PDT Received: from gaea.synopsys.com by chronos.synopsys.com with SMTP id AA05192 (5.65c/IDA-1.4.4 for ); Wed, 10 Aug 1994 14:40:31 -0700 Received: from clotho (clotho.synopsys.com) by gaea.synopsys.com with SMTP id AA01116 (5.65c/IDA-1.4.4); Wed, 10 Aug 1994 14:40:29 -0700 Received: from tonga.synopsys.com (tonga.synopsys.com [146.225.82.16]) by clotho (8.6.9/8.6.9) with SMTP id OAA01384; Wed, 10 Aug 1994 14:40:29 -0700 Date: Wed, 10 Aug 1994 14:40:29 -0700 Message-Id: <199408102140.OAA01384@clotho> X-Sender: randyh@engr.synopsys.com Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii" To: "John Brennan (446-6982)" , ibis@vhdl.org From: randyh@Synopsys.COM (Randolph E. "Randy" Harr) Subject: Re: S2IBIS X-Mailer: Sorry, my fault. It is fixed now. At 04:36 PM 8/10/94 EDT, John Brennan (446-6982) wrote: >Greetings, > >I could not load s2ibis10.tar.Z due to insufficient access. >If I read the previous note correctly this should be public now? >All users do not have read authority yet. s2ibis.zip has general read access. > >Thanks again, >John Brennan > > Randolph E. (randy) Harr Senior Scientist and Program Manager Logic Modeling Group, Synopsys Inc. randyh@synopsys.com, (415) 694-1835 (voice) From bward@Starbase.NeoSoft.COM Wed Aug 10 18:37:35 1994 Return-Path: Received: from Starbase.NeoSoft.COM by vhdl.vhdl.org (4.1/SMI-4.1/BARRNet) id AA21481; Wed, 10 Aug 94 18:37:35 PDT Received: (from bward@localhost) by Starbase.NeoSoft.COM (8.6.9/8.6.9) id UAA29772; Wed, 10 Aug 1994 20:33:28 -0500 Date: Wed, 10 Aug 1994 20:33:28 -0500 Message-Id: <199408110133.UAA29772@Starbase.NeoSoft.COM> X-Provider: NeoSoft, Inc.: Internet Service Provider (713) 684-5969 To: ibis@vhdl.org Subject: Posters posted From: bward@neosoft.com (Bob Ward) Reply-To: bward@neosoft.com Hey all you bird watchers ! Guess what! I _am_ still here! I have posted the ibis posters ( Finally! ;-) ) to : ftp.neosoft.com /incoming/ibis.cgm Login as ftp and give your e-mail address as password. Derrick or Will, can someone upload this to vhdl.org, please? If so, I shall delete it from neosoft after you indicate its successful upload. Further can someone convert the CorelDRAW format it is in to PowerPoint form and pass that on to Syed at National Semi for me? I found that I have no means to get to Power Point. Unless cgm will work for you, Syed. Thanks in advance from me and from Syed, too ( I am sure ). -- ~-._.-~'`~-._.-~'`~-._.-~'`~-._.-~'`~-._.-~'`~-._.-~'`~-._.-~'`~-._.-~'`~-._.-~' /> | /< Bob Ward | Quality is not the absence of @\\\\\\|*|==============================-| defects as defined by the \< bward@neosoft.com | developer but the presence of \> | value as defined by the customer. _.-~'`~-._.-~'`~-._.-~'`~-._.-~'`~-._.-~'`~-._.-~'`~-._.-~'`~-._.-~'`~-._.-~'`~- Restore freedom in America! Abolish RICO! Preserve the right to bear arms! Sink the Clipper! From bob@icx.com Wed Aug 10 19:50:17 1994 Return-Path: Received: from uu4.psi.com by vhdl.vhdl.org (4.1/SMI-4.1/BARRNet) id AA21893; Wed, 10 Aug 94 19:50:17 PDT Received: by uu4.psi.com (5.65b/4.0.071791-PSI/PSINet) via UUCP; id AA22319 for ; Wed, 10 Aug 94 22:38:35 -0400 Date: Wed, 10 Aug 94 19:26:45 PDT From: bob@icx.com ( Bob Ross) Received: by icx.com (4.1/3.2.083191-Interconnectix Inc.) id AA11439; Wed, 10 Aug 94 19:26:45 PDT Message-Id: <9408110226.AA11439@icx.com> To: ibis@vhdl.org Subject: BIRD19 Comments Stephen, John and Ibis Committee: Thank you for your comments. There is a strong consistency rational for at least providing V_fixture_min and V_fixture_max. The [Ramp] dV/dt_f data is defined with a measurement setup with a 50 Ohm load tied to "POWER". For decomposition purposes, this should be the same set of voltages (typ-min-max) to which the device is connected. I believe this is how models are currently produced. The [Falling Waveform] typ-min-max tables should be capable of providing a corresponding, more detailed description of the SAME waveforms. V_fixture_min and V_fixture_max values allow defining the same voltage variations that the [Ramp] setup uses. Stephen, regarding Vref_min and Vref_max, I have given it more thought and this portion of the BIRD may not be justified because most timing specs are at one voltage. Even for Open_drain cases, the Vcc is assume fixed for min/max timing values. The most compelling consideration is that, for consistency, other parameters would have to be allowed to vary (e.g., Vmeas, Vinh, and Vinl which are technically a percentage of Vcc in CMOS technologies), and this would create an unnecessary complication in IBIS. So, unless there are objections in the next few days, I will issue a revised BIRD19.1 next week which deletes the Vref_min and Vref_max changes and deals only with V_fixture_min and V_fixture_max. Bob Ross, Interconnectix, Inc. From keith@HK.Super.NET Thu Aug 11 01:00:51 1994 Return-Path: Received: from hk.super.net by vhdl.vhdl.org (4.1/SMI-4.1/BARRNet) id AA23492; Thu, 11 Aug 94 01:00:51 PDT Received: by hk.super.net id AA27037 (5.67b/IDA-1.5 for ibis@vhdl.org); Thu, 11 Aug 1994 15:57:26 +0800 Date: Thu, 11 Aug 1994 15:57:26 +0800 From: "Mr. Keith Lawrence" Message-Id: <199408110757.AA27037@hk.super.net> To: ibis@vhdl.org Subject: Apologies. Sorry for the wasted bandwidth, but can someone please advise how I can unsub from this group? Thanks, keith@hk.super.net From randyh@Synopsys.COM Thu Aug 11 05:17:49 1994 Return-Path: Received: from chronos.synopsys.com by vhdl.vhdl.org (4.1/SMI-4.1/BARRNet) id AA27241; Thu, 11 Aug 94 05:17:49 PDT Received: from gaea.synopsys.com by chronos.synopsys.com with SMTP id AA16362 (5.65c/IDA-1.4.4 for ); Thu, 11 Aug 1994 05:13:55 -0700 Received: from clotho (clotho.synopsys.com) by gaea.synopsys.com with SMTP id AA18990 (5.65c/IDA-1.4.4); Thu, 11 Aug 1994 05:13:54 -0700 Received: from tonga.synopsys.com (tonga.synopsys.com [146.225.82.16]) by clotho (8.6.9/8.6.9) with SMTP id FAA09887; Thu, 11 Aug 1994 05:13:53 -0700 Date: Thu, 11 Aug 1994 05:13:53 -0700 Message-Id: <199408111213.FAA09887@clotho> X-Sender: randyh@engr.synopsys.com Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii" To: "Mr. Keith Lawrence" , ibis@vhdl.org From: randyh@Synopsys.COM (Randolph E. "Randy" Harr) Subject: Re: Apologies. X-Mailer: Your unsubscribed. For those of you with thoughts of this in the future, send your messages to ibis-request@vhdl.org. At 03:57 PM 8/11/94 +0800, Mr. Keith Lawrence wrote: >Sorry for the wasted bandwidth, but can someone please advise how I can >unsub from this group? > >Thanks, > >keith@hk.super.net > > > Randolph E. (randy) Harr Senior Scientist and Program Manager Logic Modeling Group, Synopsys Inc. randyh@synopsys.com, (415) 694-1835 (voice) From huq@rockie.nsc.com Thu Aug 11 08:58:54 1994 Return-Path: Received: from gatekeeper.nsc.com by vhdl.vhdl.org (4.1/SMI-4.1/BARRNet) id AA28220; Thu, 11 Aug 94 08:58:54 PDT Received: from nsc.nsc.com by gatekeeper.nsc.com (5.65/fma-120691) with SMTP; id AA13179 for ibis@vhdl.org; Thu, 11 Aug 94 08:54:46 -0700 Received: from lightning.nsc.com by nsc.nsc.com (5.65/1.34) with SMTP id AA13003 for ibis@vhdl.org; Thu, 11 Aug 94 08:54:44 -0700 Received: from kural by rockie.nsc.com (4.1/SMI-4.1) id AA06578; Thu, 11 Aug 94 08:56:14 PDT Date: Thu, 11 Aug 94 08:56:14 PDT From: huq@rockie.nsc.com (Syed Huq) Message-Id: <9408111556.AA06578@rockie.nsc.com> To: ibis@vhdl.org, bward@neosoft.com Subject: Re: Posters posted Bob, Both Powerpoint and Microsoft Word can import a .cgm file. So as long as I can get a hold of your ibis.cgm....I am happy... Regards, Syed huq National Semiconductor. > From bward@Starbase.NeoSoft.COM Wed Aug 10 18:47:07 1994 > Date: Wed, 10 Aug 1994 20:33:28 -0500 > X-Provider: NeoSoft, Inc.: Internet Service Provider (713) 684-5969 > To: ibis@vhdl.org > Subject: Posters posted > From: bward@neosoft.com (Bob Ward) > Reply-To: bward@neosoft.com > Content-Length: 1241 > > Hey all you bird watchers ! > > Guess what! I _am_ still here! > > I have posted the ibis posters ( Finally! ;-) ) to : > > ftp.neosoft.com /incoming/ibis.cgm > > Login as ftp and give your e-mail address as password. > > Derrick or Will, can someone upload this to vhdl.org, please? If so, I > shall delete it from neosoft after you indicate its successful upload. > > Further can someone convert the CorelDRAW format it is in to PowerPoint > form and pass that on to Syed at National Semi for me? I found that I > have no means to get to Power Point. Unless cgm will work for you, Syed. > Thanks in advance from me and from Syed, too ( I am sure ). > > -- > > ~-._.-~'`~-._.-~'`~-._.-~'`~-._.-~'`~-._.-~'`~-._.-~'`~-._.-~'`~-._.-~'`~-._.-~' > /> | > /< Bob Ward | Quality is not the absence of > @\\\\\\|*|==============================-| defects as defined by the > \< bward@neosoft.com | developer but the presence of > \> | value as defined by the customer. > _.-~'`~-._.-~'`~-._.-~'`~-._.-~'`~-._.-~'`~-._.-~'`~-._.-~'`~-._.-~'`~-._.-~'`~- > > Restore freedom in America! > Abolish RICO! Preserve the right to bear arms! Sink the Clipper! > > > From bward@Starbase.NeoSoft.COM Thu Aug 11 17:05:06 1994 Return-Path: Received: from Starbase.NeoSoft.COM by vhdl.vhdl.org (4.1/SMI-4.1/BARRNet) id AA01556; Thu, 11 Aug 94 17:05:06 PDT Received: (from bward@localhost) by Starbase.NeoSoft.COM (8.6.9/8.6.9) id TAA20097; Thu, 11 Aug 1994 19:00:56 -0500 Date: Thu, 11 Aug 1994 19:00:56 -0500 Message-Id: <199408120000.TAA20097@Starbase.NeoSoft.COM> X-Provider: NeoSoft, Inc.: Internet Service Provider (713) 684-5969 To: ibis@vhdl.org Subject: ibis posters reposted From: bward@neosoft.com (Bob Ward) Reply-To: bward@neosoft.com Hi, all you ibis folk! I had several pieces of mail stating there were problems getting to the neosoft ftp site. So when I tried it again today, I got there and found that my file had evaporated. It has now been reposted to vhdl.org, thanks to Derrick. It is in /pub/ibis/documents as file ibispost.cgm. I had asked that someone might format it for Power Point, but Derrick tried it and found that the cgm file could be imported into Power Point. Anyway, good luck fetching it, and enjoy it with my ( and TI's ! ) complements. -- ~-._.-~'`~-._.-~'`~-._.-~'`~-._.-~'`~-._.-~'`~-._.-~'`~-._.-~'`~-._.-~'`~-._.-~' /> | /< Bob Ward | Quality is not the absence of @\\\\\\|*|==============================-| defects as defined by the \< bward@neosoft.com | developer but the presence of \> | value as defined by the customer. _.-~'`~-._.-~'`~-._.-~'`~-._.-~'`~-._.-~'`~-._.-~'`~-._.-~'`~-._.-~'`~-._.-~'`~- Restore freedom in America! Abolish RICO! Preserve the right to bear arms! Sink the Clipper! From Derrick_Duehren@ccm2.jf.intel.com Thu Aug 11 22:44:04 1994 Return-Path: Received: from ormail.intel.com by vhdl.vhdl.org (4.1/SMI-4.1/BARRNet) id AA02791; Thu, 11 Aug 94 22:44:04 PDT Received: from relay.jf.intel.com by ormail.intel.com with smtp (Smail3.1.28.1 #12) id m0qYpM3-000MPWC; Thu, 11 Aug 94 22:40 PDT Received: from ccm.hf.intel.com by relay.jf.intel.com (Smail3.1.28.1 #2) id m0qYpKX-000twdC; Thu, 11 Aug 94 22:39 PDT Received: by ccm.hf.intel.com (ccmgate 3.0) Thu, 11 Aug 94 22:39:01 PST Date: Thu, 11 Aug 94 22:39:01 PST From: Derrick Duehren Message-Id: <940811223901_1@ccm.hf.intel.com> To: Randy_L_Wilhelm@ccm.fm.intel.com, Jerry_Budelman@ccm2.jf.intel.com, IBIS@vhdl.org Subject: IBIS 8/5/94 Meeting Minutes Text item: Text_1 Date: Aug. 11, 1994 From: Will Hobbs (503) 696-4369, fax (503) 696-4210 Will_Hobbs@ccm2.jf.intel.com XTG Modeling Manager, Intel Corp., Chairperson, IBIS Open Forum Intel Corporation 5200 NE Elam Young Pkwy, Hillsboro, Oregon 97124 USA and Derrick Duehren (503) 696-4299, fax (503) 696-4904 Derrick_Duehren@ccm.jf.intel.com Intel Program Manager Subject: Minutes from IBIS Open Forum Meeting 8/5/94 To: AT&T Global Info Systems Dave Moxley Anacad Steffen Rochel Ansoft Henri Maramis Atmel Corporation Dan Terry Cadence Design Sandeep Khanna, C. Kumar* Cadlab Ralf Bruning Contec Maah Sango Digital Equipment Corp. Barry Katz* EIA Patty Rusher High Design Technology Michael Smith, Dr. Ing. Cosso HyperLynx Kellee Crisafulli* IBM Jay Diepenbrock, Joseph Flanigan IBM-Motorola alliance Lynn Warriner, Hoa Quoc, John Burnett Integrated Silicon Systems Eric Bracken Integrity Engineering Greg Doyle Intel Corporation Stephen Peters, Don Telian, Will Hobbs* Arpad Muranyi*, Derrick Duehren*, John Keifer Interconnectix, Inc. Bob Ross*, Scott Bloom* Intergraph Ian Dodd, David Wiens IntuSoft Charles Hymowitz Mentor Graphics Ravender Goyal Meta-Software Mei Wong, You-Pang Wei, John Sliney, NEC Hiroshi Matsumoto MicroSim Arthur Wong National Semiconductor Syed Huq* North Carolina State U. Steve Lipa, Michael Steer* OptEM Engineering, Inc. Benny Leveille, Ken Ehn PC Ware Paul Munsey Quad Design Jon Powell Quantic Labs Mike Ventham Racal-Redac John Berrie Siemens Nixdorf Werner Rissiek, Olaf Rethmeier* Symmetry Martin Walker Synopsys, Logic Modeling G. Randy Harr* Texas Instruments Bob Ward Thomson-CSF/SCTF Jean Lebrun UniCAD Canada Ltd. Stephen Lum Zeelan Technology George Opsahl, Hiro Moriyasu CC: Intel Corporation Randy Wilhelm, Jerry Budelman, Intel IBIS team In the list above, attendees at the meeting are indicated by * Upcoming Meetings: The room and bridge numbers for future IBIS teleconferences are listed below: Date Bridge Number Reservation # 8/26/94 (415) 904-8944 #809164 9/16/94 (415) 904-8944 #809164 10/7/94 (415) 904-8944 #809164 All meetings are 8:00 AM to 10:00 AM PDT (15:00 to 17:00 UTC). 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. NOTE: "AR" = Action Required. ------------------------------------------------------------------------ Meeting Agenda -------------- Check-in Intros of new IBIS participants Hobbs Review of previous meeting's minutes Hobbs Miscellany/Announcements/Treasurer's report Hobbs Opens for new issues All Press updates Hobbs/All Progress toward enlisting new IC vendors All New models available All Golden Parser, 2.1 plans Hobbs IBIS Librarian Powell Standards body affiliation Hobbs Spice-to-IBIS Converter Ross Pending BIRDs Hobbs Wrap-up, Next Meeting Plans Hobbs Check-in, Intros, Announcements There were no new participants. There were no corrections made to last month's minutes. Nothing new to report on finances. There were no new issues. There were no press updates reported. There was no new public model availability announced. Will announced that Intel is distributing IBIS models of unannounced parts under non-disclosure. Progress toward enlisting new IC vendors Syed is presenting IBIS to multiple groups within National Semi. AR Will: Send your PowerPoint slide file to Syed. [DONE] Texas Instruments has published a Spice model Databook on a 3.5" disk. NCSU proposes using these models as test input to the Spice-to-IBIS converter. Golden Parser, 2.1 We discussed funding the new parser. It was agreed that we can start collecting funds. AR Derrick: Post an "invoice" for the rev 2.0 GP for companies that are ready to buy-in now. Old AR Stephen: Generate V2.0 test files for Paul by Aug. 1. Old AR Kumar: Generate V2.0 package test files for Paul by Aug. 1. Old AR Stephen: Start an evaluation/validation-plan discussion on the reflector. [STARTED] IBIS Librarian Michael Steer of NCSU has submitted a proposal to have NCSU provide the librarian function while keeping the files on the vhdl.org machine. Vote taken to approve Michael Steer's proposal, there were no objections. AR Michael: Post procedures for companies to post IBIS files. Disclaimer issue: Librarian to add a line or two to point to a longer disclaimer statement. AR Michael: Propose a longer statement and send it to Derrick Duehren for legal review. Standards Body Affiliation Will proposed affiliation to the EIA after ratification of IBIS Rev 2.1. The DIE group, which uses IBIS and is funded by ARPA within the EIA, has volunteered to help guide IBIS through the standards process along with the DIE spec. ARPA funding ends this year. We would still retain control. Advisory vote taken: Unanimously approved. ====> A binding vote will be taken at the 8/26/94 meeting. <==== Spice-to-IBIS Converter Bob Ross and Scott Bloom reported that the V1.1 converter will be posted soon. Berkeley 2,3, Pspice, Hspice support on Sun, DEC, HP700 Series, and RS6000. They are having memory limitations running on DOS. Kellee suggested running it under Windows 32 to avoid the memory problems. AR Derrick: Retrieve files from \incoming and post them to \s2ibis. [DONE] BIRD 17, Number of Data Points We continued the debate that has been on the reflector. We need to either kill this BIRD or increase the number of pins past 101. AR Arpad to talk with Meta-Software and get their comments on this issue. BIRD 18.2, [Diff Pin] Parameter Order Vote taken on BIRD 18.2, approved unanimously. V_fixture sub-keyword Not discussed. AR: Bob Ross, post this as BIRD 19. Wrap-up, Next Meeting Plans Our next meeting is 8/26/94. ============================================================================== NOTES If you know of someone new who wants to join the e-mail reflector (ibis@vhdl.org), send e-mail to ibis-request@vhdl.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 (408-945-4170), or send an email request to the automatic archive server, archive@vhdl.org. ============================================================================== From bob@icx.com Sat Aug 13 18:48:30 1994 Return-Path: Received: from uu4.psi.com by vhdl.vhdl.org (4.1/SMI-4.1/BARRNet) id AA19613; Sat, 13 Aug 94 18:48:30 PDT Received: by uu4.psi.com (5.65b/4.0.071791-PSI/PSINet) via UUCP; id AA12553 for ; Sat, 13 Aug 94 21:37:48 -0400 Date: Sat, 13 Aug 94 18:25:46 PDT From: bob@icx.com ( Bob Ross) Received: by icx.com (4.1/3.2.083191-Interconnectix Inc.) id AA21320; Sat, 13 Aug 94 18:25:46 PDT Message-Id: <9408140125.AA21320@icx.com> To: ibis@vhdl.org Subject: BIRD19.1 IBIS Members: BIRD19.1 is a revision of BIRD19 to deal only with V_fixture_min and V_fixture_max subparameters. Bob Ross, Interconnectix, Inc. ***************************************************************************** ***************************************************************************** Buffer Issue Resolution Document (BIRD) BIRD ID#: 19.1 ISSUE TITLE: V_fixture Subparameter Min/Max Additions REQUESTOR: Bob Ross, Interconnectix, Inc. DATE SUBMITTED: 8 August 1994 DATE REVISED: 13 August 1994 DATE ACCEPTED BY IBIS OPEN FORUM: Pending ****************************************************************************** ****************************************************************************** STATEMENT OF THE ISSUE: There are cases with respect to certain devices including CMOS logic where the [Rising Waveform] and [Falling Waveform] fixture load specifications are not adequate to define the min and max table loads. Additional sub- parameters for [Rising Waveform] and [Falling Waveform] are proposed: V_fixture_min and V_fixture_max. ****************************************************************************** STATEMENT OF THE RESOLVED SPECIFICATIONS: The [Rising Waveform], [Falling Waveform] keyword description is presented along with changes in the text related to including the sub-parameters "V_fixture_min" and "V_fixture_max". Changed lines are designated by "|*". |============================================================================== | Keywords: [Rising Waveform], [Falling Waveform] | Required: No | Description: Describes the shape of the rising and falling edge | waveforms of a driver. |* Sub-Params: R_fixture, V_fixture, V_fixture_min, V_fixture_max, |* C_fixture, L_fixture, | R_dut, L_dut, C_dut | Usage Rules: Each [Rising Waveform] and [Falling Waveform] keyword | introduces a table of time vs. voltage points that | describe the shape of an output waveform. These | time/voltage points are taken under the conditions | specified in the R/L/C/V_fixture and R/L/C_dut | sub-parameters. The table itself consists of | one column of time points, then three columns of | voltage points in the standard typ, min, and max format. | The four entries must be placed on a single line and | must be separated by at least one white space or tab | character. All four columns are required. However, data | is only required in the typical column. If minimum | or maximum data is not available, use the reserved word | "NA". The first value in the time column need not be '0'. | Time values must increase as one parses down the table. | The waveform table can contain a maximum of 100 data | points. A maximum of 100 waveform tables are allowed per | model. Note that for backwards compatibility, the existing | [Ramp] keyword is still required. | | A waveform table must include the entire waveform; | i.e., the first entry (or entries) in a voltage column | must be the DC voltage of the output before switching | and the last entry (or entries) of the column must be | the final DC value of the output after switching. | | A [Model] specification can contain more than one rising | edge or falling edge waveform table. However, each new | table must begin with the appropriate keyword and sub- | parameter list as shown below. If more than one rising or | falling edge waveform table is present, then the data in | each of the respective tables must be time correlated. | In other words, the rising (falling) edge data in each | of the rising (falling) edge waveform tables must be | entered with respect to a common reference point on the | input stimulus waveform. | | The 'fixture' sub-parameters specifies the loading | conditions under which the waveform is taken. The R_dut, | C_dut, and L_dut Sub-params are analogous to the | package parameters R_pkg, C_pkg and L_pkg and are used | if the waveform includes the effects of pin | inductance/capacitance. The diagram below shows the | interconnection of these elements. | | PACKAGE | TEST FIXTURE | _________ | | | DUT | L_dut R_dut | L_fixture R_fixture | | die |---@@@@@--/\/\/\--o-----|--@@@@---o---/\/\/\----- V_fixture | |_________| | | | | | | | | | | | | C_dut === | === C_fixture | | | | | | | | | GND | GND | | Only the R_fixture and V_fixture sub-parameters are | required, the rest of the sub-parameters are optional. | If a sub-parameter is not used, its value defaults to | zero. The sub-parameters must appear in the text after | the keyword and before the first row of the waveform | table. | |* V_fixture defines the voltage for typ, min and max |* supply conditions. However, when the fixture voltage |* is related to the power supply voltages, then the |* sub-parameters V_fixture_min and V_fixture_max can |* be used to further specify the fixture voltage for |* min and max supply voltages. |* |------------------------------------------------------------------------------ [Rising Waveform] R_fixture = 500 V_fixture = 5.0 |* V_fixture_min = 4.5 |Note, R_fixture is connected to Vcc |* V_fixture_max = 5.5 |Specified, but not used in this example C_fixture = 50p L_fixture = 2n C_dut = 7p R_dut = 1m L_dut = 1n |Time V(typ) V(min) V(max) 0.0ns 0.3 0.5 NA 0.5ns 0.3 0.5 NA 1.0ns 0.6 0.7 NA 1.5ns 0.9 0.9 NA 2.0ns 1.5 1.3 NA 2.5ns 2.1 1.7 NA 3.0ns 3.0 2.7 NA 3.5ns 3.2 3.0 NA | [Falling Waveform] R_fixture = 50 V_fixture = 0 |Time V(typ) V(min) V(max) 10.0ns 3.2 3.0 NA 10.5ns 3.0 2.7 NA 11.0ns 2.1 1.7 NA 11.5ns 1.5 1.3 NA 12.0ns 0.9 0.9 NA 12.5ns 0.6 0.7 NA 13.0ns 0.3 0.5 NA 13.5ns 0.3 0.5 NA | |============================================================================= ****************************************************************************** ANALYSIS PATH/DATA THAT LED TO SPECIFICATION John Brennan writes 7/29/94, "I have a question on the V_fixture ibis sub-keyword for [Falling Waveform]. This variable appears to expect 1 value, ie, typically the nominal power supply value. Since I use the same deck to measure [Ramp] as [Falling Waveform], my deck has the load resistor hooked to the power supply, which will be different for typ, min and max." "Does this present a problem to the simulation vendor that V_fixture cannot handle a min and max value, or If I enter three values will they be handled correctly. Should I change my deck so the the load resistor is hooked to the nominal supply value and not vary it for min and max?" "How important is V_fixture? Also, are the values in the example in spec ver2.0 backwards? Wouldn't a [Falling Waveform] be pulling against a logic "1" voltage, and a [Rising waveform] be pulling against a GND type voltage?" Bob Ross responds 7/29/94, "My initial response is that you uncovered a valid condition which we did not consider fully. We should have allowed a V_fixture_min, and V_fixture_max for cases where the fixture is tied to Vcc or for cases where it represents the Thevenin voltage (and can change). The same will apply for the [Model] subparameter Vref. It may need a Vref_min and Vref_max also. This should be the subject for further consideration and probably a BIRD." An alternative approach would be to redefine V_fixture and Vref similar to the C_comp subparameter on one line in the typ_min_max format. This was not chosen because it could create an unnecessary enlargement of IBIS Version 2.1 to be compatible with IBIS Version 2.0 and also because the additional sub-parameters introduced here may be used less frequently. For completeness, V_fixture_typ and Vref_typ could also have been introduced. However, with the current definition, these are redundant. The proposed additions in BIRD19 of Vref_min and V_ref_max subparameters of [Model] have been deleted in BIRD19.1 because they are typically not used in timing specifications. ****************************************************************************** ANY OTHER BACKGROUND INFORMATION As additional information, a similar problem was encountered in specifying the input waveform amplitudes for the s2ibis program under min and max supply conditions. This is particularly applicable for CMOS logic where a typical voltage range is from 0V to 5V. However, if the supply voltage is at min (say 4.5V), one would expect the Input voltage range to be from 0V to 4.5V). The default condition for s2ibis for IBIS Version 1.1 is to adjust the Input Voltage directly proportional to Vcc. So for a typical TTL Input specification, the Input voltage specified from 0V to 3V is actually 0V to 3V for typ, 0V to 2.5V for min, and 0V to 3.5V for max for a +/- .5V Vcc change. This default condition (which defines the SPICE PULSE command) can be overridden (along with the default Input ramp rise and fall times of .1ns) under each condition by optional specifications: **Input_Ramp_min **Input_ramp_typ **Input_ramp_max So with these specifications, the Input ramp specification can be set to a fixed voltage range such as 0V to 3V for typ-min-max extractions. From Arpad_Muranyi@ccm.fm.intel.com Thu Aug 18 12:19:53 1994 Return-Path: Received: from ormail.intel.com by vhdl.vhdl.org (4.1/SMI-4.1/BARRNet) id AA05746; Thu, 18 Aug 94 12:19:53 PDT Received: from relay.jf.intel.com by ormail.intel.com with smtp (Smail3.1.28.1 #12) id m0qbC5l-000MVXC; Thu, 18 Aug 94 11:21 PDT Received: from ccm.hf.intel.com by relay.jf.intel.com (Smail3.1.28.1 #2) id m0qbC5l-000tweC; Thu, 18 Aug 94 11:21 PDT Received: by ccm.hf.intel.com (ccmgate 3.0) Thu, 18 Aug 94 11:21:32 PST Date: Thu, 18 Aug 94 11:21:32 PST From: Arpad Muranyi Message-Id: <940818112132_1@ccm.hf.intel.com> To: ibis@vhdl.org Subject: Voltage ranges Text item: Text_1 Hi IBIS folks, I had an AR to find out how SPICE people feel about the "100 point limit". From the answers I received from three different SPICE simulation tool vendors I concluded that there is no need to limit the data to 100 points. That's all I want to say about this now, but we can discuss it in more detail on the next Open Forum meeting. Along the same lines, I would like to extend each I-V curve to cover the same voltage span. Currently the GND clamp and POWER clamp curves are limited to a smaller range than the pulldown and pullup curves. I see the need for this when there is a weak pullup (or pulldown) "resistor" in a buffer or receiver. The current understanding is that these kinds of "resistors" can be put into the 0 to 5V range of the GND clamp curve. However, putting a Vcc-relative pullup resistor into a ground relative GND clamp curve creates a bunch of problems. For this reason, it would be nice to be able to put the pullup "resistors" into the POWER clamp curve, but it's voltage range - as defined in ver1.1 (and 2.0) - does not provide room for it. The logical step would be to extend it's range to be the same as the GND clamp's range is. But then why not just make all of the ranges the same for simplicity sake? When I wrote about this before, some people responded that they view the specified ranges as minimum required ranges and it did not matter if I published wider ranges in my models. However, I looked up in the ver1.1 spec, and it says: "Points for each curve must span the voltages listed below" which means no more and no less. I am about to release a new set of models in which I will most likely violate the spec. by using exdended voltage ranges in some of the clamp curves. Since I do not want to get blamed for changing my mind all the time, I would like to hear what you, IBIS people think about releasing such models before I do so. I must admit that I am not one of those Godly people who can see into the future, so when I wrote ver1.1 I did not see this problem coming. Sincerely Arpad Muranyi Intel Corporation From bob@icx.com Sat Aug 20 14:20:15 1994 Return-Path: Received: from uu4.psi.com by vhdl.vhdl.org (4.1/SMI-4.1/BARRNet) id AA23932; Sat, 20 Aug 94 14:20:15 PDT Received: by uu4.psi.com (5.65b/4.0.071791-PSI/PSINet) via UUCP; id AA26213 for ; Sat, 20 Aug 94 17:05:27 -0400 Date: Sat, 20 Aug 94 13:51:16 PDT From: bob@icx.com ( Bob Ross) Received: by icx.com (4.1/3.2.083191-Interconnectix Inc.) id AA01909; Sat, 20 Aug 94 13:51:16 PDT Message-Id: <9408202051.AA01909@icx.com> To: ibis@vhdl.org Subject: Re: Voltage Ranges Arpad and IBIS Committee: Here are some comments to respond to your last note on the above subject. 1. As we discussed, the 100 point limit still exists on some vendor's controlled voltage and current sources. What you are saying is that, if necessary, tables with more than 100 points could be reduced to 100 points or less. 2. I think it is permissible and useful to extend the voltage ranges beyond the IBIS limits on either direction to comply with real, practical considerations, regardless of the interpretation or intent of the "Points for each curve must span the voltages listed below" statement. Going beyond the span poses no technical problem with Spice based controlled elements nor with data table based elements. I also had a situation requiring modeling a weak, internal non-linear pullup element for an Open device which I resoved using an extended [Power clamp] table. So I fully support releasing any model that have tables going beyond the implied limits. 3. I do not think it is necessary to require extending the IBIS ranges for all tables to the same range because for most devices, it is of no practical impact when the currents are equal or nearly equal to 0 ma. Only when there is a need should an extension be considered. 4. By providing tables referenced to various Voltage rails, you along with others did provide an important architectural contribution for using IBIS to transfer model information for current and future needs. The issue of range limits are not dictated by architectural limitations or acquisition of data, but by some practical considerations needed to directly map the data into certain simulator constructs. In all cases, care needs to be taken to decompose any sources of current into the appropriate tables and to avoid double entries of the same current. Even the "min" and "max" tables may have some minor, inconsequential violation of this with a .5 V overlap when Vcc = 4.5V and a .5V gap when Vcc = 5.5V for a -5V to 5V span of the [GND_clamp] table. Bob Ross, Interconnectix, Inc. From lfs@Synopsys.COM Mon Aug 22 15:24:21 1994 Return-Path: Received: from chronos.synopsys.com by vhdl.vhdl.org (4.1/SMI-4.1/BARRNet) id AA14656; Mon, 22 Aug 94 15:24:21 PDT Received: from gaea.synopsys.com by chronos.synopsys.com with SMTP id AA24788 (5.65c/IDA-1.4.4 for ); Mon, 22 Aug 1994 15:20:51 -0700 Received: from sauron-100.synopsys.com (sauron-64.synopsys.com) by gaea.synopsys.com with SMTP id AA06265 (5.65c/IDA-1.4.4); Mon, 22 Aug 1994 15:20:47 -0700 Received: from tahiti-pc.synopsys.com by sauron-100.synopsys.com with SMTP id AA03916 (5.65c/IDA-1.4.4); Mon, 22 Aug 1994 15:20:46 -0700 Date: Mon, 22 Aug 1994 15:20:46 -0700 Message-Id: <199408222220.AA03916@sauron-100.synopsys.com> X-Sender: lfs@engr Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii" To: omf@cfi.org, ibis@vhdl.org From: lfs@Synopsys.COM (Larry Saunders) Subject: DIE Information Exchange for Timing (DIET) Format X-Mailer: The DIET Format is an unambiguous, EDA-tool processable, human-readable exchange format for specifying timing information about bare die and will represent data in typical IC component manufacturer provided format. It is initially intended for use in MCM design processes and will cover all aspects of bare die timing including specification and checking. It is intended to cover component required timing information, not instance or designer specific information and will provide specification of timing for complex, IC level components intended for MCM level use, not ASIC gate level components. The format is intended to replace the many ad-hoc formats in use today by EDA tools and MCM foundries and to provide a mechanism for IC manufacturers to provide important information about their products in a computer-sensible form. Preliminary information about the DIET Format semantics and syntax is available electronically. A workshop to review the DIET format is scheduled for Tuesday, May 13th and Wednesday, May 14th, 1994. Location has not be decided but it will somewhere in the San Francisco Bay area. The intent of this workshop will be to review existing work on this topic and set goals and direction for future work. Long term plans for standardization (EIA, CFI or IEEE) will be discussed also. For more information about the DIET Format or the workshop, please contact me at lfs@synopsys.com (email), 415-694-4490 (fax), or 415-694-1837 (voice). Larry Saunders Logic Modeling Group Larry Saunders lfs@mcimail.com or lfs@synopsys.com 408-894-0119 415-694-1837 408-894-0119 (fax) 415-962-8637 (fax) 1426 Cedarmeadow Ct 700 East Middlefield Rd, Bldg C San Jose, CA Mountain View, CA 95131 94043-4033 From Derrick_Duehren@ccm2.jf.intel.com Mon Aug 22 18:22:32 1994 Return-Path: Received: from ormail.intel.com by vhdl.vhdl.org (4.1/SMI-4.1/BARRNet) id AA15504; Mon, 22 Aug 94 18:22:32 PDT Received: from relay.jf.intel.com by ormail.intel.com with smtp (Smail3.1.28.1 #12) id m0qckVz-000MQ1C; Mon, 22 Aug 94 18:19 PDT Received: from ccm.hf.intel.com by relay.jf.intel.com (Smail3.1.28.1 #2) id m0qckVy-000twcC; Mon, 22 Aug 94 18:19 PDT Received: by ccm.hf.intel.com (ccmgate 3.0) Mon, 22 Aug 94 18:19:02 PST Date: Mon, 22 Aug 94 18:19:02 PST From: Derrick Duehren Message-Id: <940822181902_1@ccm.hf.intel.com> To: IBIS@vhdl.org Subject: IBIS: Changing Comment Characters Text item: Text_1 At DAC, someone had asked when changed comment characters take effect. I think someone tested it and posted the result to the reflector, but now I can't find the answer. Is it effective at the beginning of the next line? - Derrick Intel Corp. From lfs@Synopsys.COM Tue Aug 23 09:02:01 1994 Return-Path: Received: from chronos.synopsys.com by vhdl.vhdl.org (4.1/SMI-4.1/BARRNet) id AA25211; Tue, 23 Aug 94 09:02:01 PDT Received: from gaea.synopsys.com by chronos.synopsys.com with SMTP id AA07456 (5.65c/IDA-1.4.4 for ); Tue, 23 Aug 1994 08:58:32 -0700 Received: from sauron-100.synopsys.com (sauron-64.synopsys.com) by gaea.synopsys.com with SMTP id AA03180 (5.65c/IDA-1.4.4); Tue, 23 Aug 1994 08:58:30 -0700 Received: from tahiti-pc.synopsys.com by sauron-100.synopsys.com with SMTP id AA22112 (5.65c/IDA-1.4.4); Tue, 23 Aug 1994 08:58:29 -0700 Date: Tue, 23 Aug 1994 08:58:29 -0700 Message-Id: <199408231558.AA22112@sauron-100.synopsys.com> X-Sender: lfs@engr Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii" To: omf@cfi.org, ibis@vhdl.org From: lfs@Synopsys.COM (Larry Saunders) Subject: DIE Information Exchange for Timing (DIET) Format X-Mailer: My apologies on the date of the meeting. It should be September 13th and 14th, not May. Sorry. The DIET Format is an unambiguous, EDA-tool processable, human-readable exchange format for specifying timing information about bare die and will represent data in typical IC component manufacturer provided format. It is initially intended for use in MCM design processes and will cover all aspects of bare die timing including specification and checking. It is intended to cover component required timing information, not instance or designer specific information and will provide specification of timing for complex, IC level components intended for MCM level use, not ASIC gate level components. The format is intended to replace the many ad-hoc formats in use today by EDA tools and MCM foundries and to provide a mechanism for IC manufacturers to provide important information about their products in a computer-sensible form. Preliminary information about the DIET Format semantics and syntax is available electronically. A workshop to review the DIET format is scheduled for Tuesday, September 13th and Wednesday, September 14th, 1994. Location has not be decided but it will somewhere in the San Francisco Bay area. The intent of this workshop will be to review existing work on this topic and set goals and direction for future work. Long term plans for standardization (EIA, CFI or IEEE) will be discussed also. For more information about the DIET Format or the workshop, please contact me at lfs@synopsys.com (email), 415-694-4490 (fax), or 415-694-1837 (voice). Larry Saunders Logic Modeling Group Larry Saunders lfs@mcimail.com or lfs@synopsys.com 408-894-0119 415-694-1837 408-894-0119 (fax) 415-962-8637 (fax) 1426 Cedarmeadow Ct 700 East Middlefield Rd, Bldg C San Jose, CA Mountain View, CA 95131 94043-4033 From Will_Hobbs@ccm2.jf.intel.com Tue Aug 23 09:42:39 1994 Return-Path: Received: from ormail.intel.com by vhdl.vhdl.org (4.1/SMI-4.1/BARRNet) id AA25496; Tue, 23 Aug 94 09:42:39 PDT Received: from relay.jf.intel.com by ormail.intel.com with smtp (Smail3.1.28.1 #12) id m0qcysU-000MOeC; Tue, 23 Aug 94 09:39 PDT Received: from ccm.jf.intel.com by relay.jf.intel.com (Smail3.1.28.1 #2) id m0qcysU-000tweC; Tue, 23 Aug 94 09:39 PDT Received: by ccm.jf.intel.com (ccmgate 3.0) Tue, 23 Aug 94 09:39:13 PST Date: Tue, 23 Aug 94 09:39:13 PST From: Will Hobbs Message-Id: <940823093913_4@ccm.jf.intel.com> To: Derrick_Duehren@ccm2.jf.intel.com, IBIS@vhdl.org Subject: Re: IBIS: Changing Comment Characters Text item: Text_1 Derrick, Bob Ross tried it and it takes effect immediately. Will At DAC, someone had asked when changed comment characters take effect. I think someone tested it and posted the result to the reflector, but now I can't find the answer. Is it effective at the beginning of the next line? - Derrick Intel Corp. Text item: External Message Header The following mail header is for administrative use and may be ignored unless there are problems. ***IF THERE ARE PROBLEMS SAVE THESE HEADERS***. Subject: IBIS: Changing Comment Characters To: IBIS@vhdl.org Message-Id: <940822181902_1@ccm.hf.intel.com> From: Derrick Duehren Date: Mon, 22 Aug 94 18:19:02 PST Received: by ccm.hf.intel.com (ccmgate 3.0) Mon, 22 Aug 94 18:19:02 PST Received: from ccm.hf.intel.com by relay.jf.intel.com (Smail3.1.28.1 #2) id m0qckVy-000twcC; Mon, 22 Aug 94 18:19 PDT Received: from relay.jf.intel.com by ormail.intel.com with smtp (Smail3.1.28.1 #12) id m0qckVz-000MQ1C; Mon, 22 Aug 94 18:19 PDT Received: from ormail.intel.com by vhdl.vhdl.org (4.1/SMI-4.1/BARRNet) id AA15504; Mon, 22 Aug 94 18:22:32 PDT Received: from vhdl.vhdl.org by hermes.intel.com (5.65/10.0i); Mon, 22 Aug 94 18 Received: from hermes by ichips.intel.com (5.64+/10.0i); Mon, 22 Aug 94 18:26:22 Received: from ichips.intel.com by relay.jf.intel.com with smtp (Smail3.1.28.1 #2) id m0qckfI-000twdC; Mon, 22 Aug 94 18:28 PDT From huq@rockie.nsc.com Tue Aug 23 10:00:32 1994 Return-Path: Received: from gatekeeper.nsc.com by vhdl.vhdl.org (4.1/SMI-4.1/BARRNet) id AA25754; Tue, 23 Aug 94 10:00:32 PDT Received: from nsc.nsc.com by gatekeeper.nsc.com (5.65/fma-120691) with SMTP; id AA25651 for ibis@vhdl.org; Tue, 23 Aug 94 09:57:06 -0700 Received: from lightning.nsc.com by nsc.nsc.com (5.65/1.34) with SMTP id AA09392 for ibis@vhdl.org; Tue, 23 Aug 94 09:57:05 -0700 Received: from kural by rockie.nsc.com (4.1/SMI-4.1) id AA04666; Tue, 23 Aug 94 09:58:43 PDT Date: Tue, 23 Aug 94 09:58:42 PDT From: huq@rockie.nsc.com (Syed Huq) Message-Id: <9408231658.AA04666@rockie.nsc.com> To: ibis@vhdl.org Subject: IBIS - DIET - OMF Cc: cjfgsc@tevm2.nsc.com Hi, Recently I came across an article in Electronic Engineering Times about a Modeling standard called OMF(Open Model Forum). This forum uses Logic Modeling's Swift as an interface and they are a part of CFI(CAD Framework Initiative). OMF is trying to standardize it's methodology and has over 40 EDA, semi- conductor and model vendors as members. OMF's main goal is model inter operability, protection of IC vendors intellectual property... This to me seems very similar to IBIS. Also, I have been getting copied on the DIET(Die Information Exchange for Timing)mettings coming up. I thought the DIE forum references IBIS for Signal Integrity Analysis. Then what is this DIET ?? I am sure there are IBIS members who participate in both the OMF and DIET forums. How about making some comments about the key differences between all these forums.. Regards, Syed huq National Semiconductor From mbs@eos.ncsu.edu Tue Aug 23 11:00:02 1994 Return-Path: Received: from mbs.ece.ncsu.edu (c11058-335dan.ece.ncsu.edu) by vhdl.vhdl.org (4.1/SMI-4.1/BARRNet) id AA26148; Tue, 23 Aug 94 11:00:02 PDT Received: by mbs.ece.ncsu.edu (5.65/Eos/C-U-09Sep93) id AA08708; Tue, 23 Aug 1994 13:56:33 -0400 From: mbs@eos.ncsu.edu Message-Id: <9408231756.AA08708@mbs.ece.ncsu.edu> To: ibis@vhdl.org Subject: Librarian Date: Tue, 23 Aug 94 13:56:33 EDT Folks, I have been out of town and so have not finished the Librarian protocol. There is some incoming Librarian mail so I will address it first and then send the protocal out for review. Michael From Will_Hobbs@ccm2.jf.intel.com Tue Aug 23 11:01:30 1994 Return-Path: Received: from ormail.intel.com by vhdl.vhdl.org (4.1/SMI-4.1/BARRNet) id AA26192; Tue, 23 Aug 94 11:01:30 PDT Received: from relay.jf.intel.com by ormail.intel.com with smtp (Smail3.1.28.1 #12) id m0qd06Z-000MP5C; Tue, 23 Aug 94 10:57 PDT Received: from ccm.jf.intel.com by relay.jf.intel.com (Smail3.1.28.1 #2) id m0qd06Z-000twmC; Tue, 23 Aug 94 10:57 PDT Received: by ccm.jf.intel.com (ccmgate 3.0) Tue, 23 Aug 94 10:57:50 PST Date: Tue, 23 Aug 94 10:57:50 PST From: Will Hobbs Message-Id: <940823105750_6@ccm.jf.intel.com> To: huq@rockie.nsc.com, ibis@vhdl.org Cc: cjfgsc@tevm2.nsc.com Subject: Re: IBIS - DIET - OMF Text item: Syed, Derrick Duehren and I are on the executive committee of OMF, and Randy Harr has phoned in a couple of times. Several companies, such as Cadence, Mentor and Intel, are in both IBIS and OMF, but the individuals are generally different. OMF is aimed at logic models, such as VHDL and Verilog. We are trying to define a common procedural interface to the simulators so that models can be developed in any suitable language, compiled to that interface, and run. Interestingly, TI requested that the standard allow IBIS information to be contained in the OMF API-compliant model, and this has become a goal, though not a requirement. So far, we have moved from a good idea to a CFI-affiliated group with a dozen paying participants and an additional 25 companies involved in the OMF effort. We have created a set of requirements and issued a request for technology (RFT) to use as a starting point for the API. So far, LMG has submitted Swift, but the request is still open and other submissions are expected. There are many similarities between IBIS and OMF, in that the goals are to increase availability of models through standard interface definitions, with strong protection for IP. Give me a call if you want to know more. DIET is a group headed by Randy Harr to define a spec for the transport of physical information of bare die, and that effort started about the same time as IBIS. Randy incorporated IBIS into the DIE spec, since they needed a signal integrity representation mechanism and IBIS fit well with the format and intent of DIE. Will Hobbs Intel Corp. Hi, Recently I came across an article in Electronic Engineering Times about a Modeling standard called OMF(Open Model Forum). This forum uses Logic Modeling's Swift as an interface and they are a part of CFI(CAD Framework Initiative). OMF is trying to standardize it's methodology and has over 40 EDA, semi- conductor and model vendors as members. OMF's main goal is model inter operability, protection of IC vendors intellectual property... This to me seems very similar to IBIS. Also, I have been getting copied on the DIET(Die Information Exchange for Timing)mettings coming up. I thought the DIE forum references IBIS for Signal Integrity Analysis. Then what is this DIET ?? I am sure there are IBIS members who participate in both the OMF and DIET forums. How about making some comments about the key differences between all these forums.. Regards, Syed huq National Semiconductor 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: cjfgsc@tevm2.nsc.com Subject: IBIS - DIET - OMF To: ibis@vhdl.org Message-Id: <9408231658.AA04666@rockie.nsc.com> From: huq@rockie.nsc.com (Syed Huq) Date: Tue, 23 Aug 94 09:58:42 PDT Received: from kural by rockie.nsc.com (4.1/SMI-4.1) id AA04666; Tue, 23 Aug 94 09:58:43 PDT Received: from lightning.nsc.com by nsc.nsc.com (5.65/1.34) with SMTP id AA09392 for ibis@vhdl.org; Tue, 23 Aug 94 09:57:05 -0700 Received: from nsc.nsc.com by gatekeeper.nsc.com (5.65/fma-120691) with SMTP; id AA25651 for ibis@vhdl.org; Tue, 23 Aug 94 09:57:06 -0700 Received: from gatekeeper.nsc.com by vhdl.vhdl.org (4.1/SMI-4.1/BARRNet) id AA25754; Tue, 23 Aug 94 10:00:32 PDT Received: from vhdl.vhdl.org by hermes.intel.com (5.65/10.0i); Tue, 23 Aug 94 10 Received: from hermes by ichips.intel.com (5.64+/10.0i); Tue, 23 Aug 94 10:08:58 Received: from ichips.intel.com by relay.jf.intel.com with smtp (Smail3.1.28.1 #2) id m0qczNd-000twcC; Tue, 23 Aug 94 10:11 PDT From lfs@Synopsys.COM Tue Aug 23 11:28:06 1994 Return-Path: Received: from chronos.synopsys.com by vhdl.vhdl.org (4.1/SMI-4.1/BARRNet) id AA26278; Tue, 23 Aug 94 11:28:06 PDT Received: from gaea.synopsys.com by chronos.synopsys.com with SMTP id AA11189 (5.65c/IDA-1.4.4 for ); Tue, 23 Aug 1994 11:21:12 -0700 Received: from sauron-100.synopsys.com (sauron-64.synopsys.com) by gaea.synopsys.com with SMTP id AA13679 (5.65c/IDA-1.4.4); Tue, 23 Aug 1994 11:21:08 -0700 Received: from tahiti-pc.synopsys.com by sauron-100.synopsys.com with SMTP id AA04395 (5.65c/IDA-1.4.4); Tue, 23 Aug 1994 11:21:07 -0700 Date: Tue, 23 Aug 1994 11:21:07 -0700 Message-Id: <199408231821.AA04395@sauron-100.synopsys.com> X-Sender: lfs@engr Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii" To: dackley@ichips.intel.com (Dave Ackley) From: lfs@Synopsys.COM (Larry Saunders) Subject: DIE Information Exchange for Timing (DIET) Format Cc: ibis@vhdl.org, omf@cfi.org, geoff@cadence.com, cpk@cadence.com, graham@cfi.org, gilman@wash.inmet.com X-Mailer: >Hi Larry > >We are most interested in existing and proposed industry standards and the >DIET timing information for complex ICs sounds most interesting. I would >appreciate any additional information you could send us about DIET and how >it relates to Vital. > >Thanks > Dave Ackley > dackley@ichips.intel.com > DIET is a new format concerned with representing timing for static and dynamic (simulation models) timing analysis of complex digital component models. LMG, Synopsys Inc. has three different file formats for model timing information -- each based on a different modeling technique. There is no need for this. Mentor G has their own static timing format embedded in their technology files. The DIET format, along the lines of the DIE work LMG has done, is meant to make it easy for IC manufacturers to deliver timing information in a computer sensible format. The efforts grew out of our DIE format work as a need identified by users and IC manufacturers. The major difference between VITAL and DIET is that DIET is black-box oriented and VITAL is clear-box oriented. DIET is about describing the generic, external timing characteristics of complex components - the timing information that IC manufacturers deliver to users of their components. Usage specific timing data is not included. Internal behavior and timing are not included. Generally, some program would read DIET data along with MCM or board netlist information and generate MCM or board specific timing information for use by some static or dynamic timing analysis tool. There is intent to avoid dealing with the detailed internal behavior of the part. VITAL is about describing the usage specific, internal timing characteristics of complex components where the gate level structure of the model is known. Generally, some program would read VITAL data and generate component specific timing information for use by some static or dynamic timing analysis tool. There is intent to deal with the detailed internal behavior of the part. I suppose the subset of VITAL information concerned with describing the I/O timing characteristics of a complex component could be used as a basis for constructing a DIET description. The only real overlap I see between the two formats is the case where some component contains a megacell. If the internal structure and behavior of the megacell is not known or irrelevant, then DIET may be the way to describe the external timing characteristics of the megacell. I'm not sure how VITAL could handle the situation. I expect to have a Language Reference Manual and maybe an example or two available sometime next week. This information will be available on the VHDL.ORG machine. I will send out a notice when it is ready along with an explanation of how to access the files. From original announcement: >The DIET Format is an unambiguous, EDA-tool processable, human-readable >exchange format for specifying timing information about bare die and will >represent data in typical IC component manufacturer provided format. It is >initially intended for use in MCM design processes and will cover all >aspects of bare die timing including specification and checking. It is >intended to cover component required timing information, not instance or >designer specific information and will provide specification of timing for >complex, IC level components intended for MCM level use, not ASIC gate >level components. The format is intended to replace the many ad-hoc formats >in use today by EDA tools and MCM foundries and to provide a mechanism for >IC manufacturers to provide important information about their products in a >computer-sensible form. > >Preliminary information about the DIET Format semantics and syntax is >available electronically. Larry Saunders lfs@mcimail.com or lfs@synopsys.com 408-894-0119 415-694-1837 408-894-0119 (fax) 415-962-8637 (fax) 1426 Cedarmeadow Ct 700 East Middlefield Rd, Bldg C San Jose, CA Mountain View, CA 95131 94043-4033 From Ravender_Goyal@pdxml1.mentorg.com Tue Aug 23 13:31:56 1994 Return-Path: Received: from newsgw.mentorg.com by vhdl.vhdl.org (4.1/SMI-4.1/BARRNet) id AA26835; Tue, 23 Aug 94 13:31:56 PDT Received: from wv.mentorg.com by newsgw.mentorg.com (8.6.4/CF5.22R) id QAA28018; Tue, 23 Aug 1994 16:27:29 -0400 Received: from pdxml1.mentorg.com by wv.mentorg.com (8.6.8.1/CF5.22R) id NAA17967; Tue, 23 Aug 1994 13:28:25 -0700 Message-Id: <199408232028.NAA17967@wv.mentorg.com> Date: 23 Aug 1994 13:24:49 -0800 From: "Ravender Goyal" Subject: Re: IBIS - DIET - OMF To: Steve_Sherwood@pdxml1.mentorg.com Cc: ibis@vhdl.org, "Syed Huq" Reply to: RE>IBIS - DIET - OMF I am forwarding this mail to Steve Sherwood who is the chairperson for OMF. Steve, can you please enlighten IBISians about your efforts on OMF. Thanks - ravender -------------------------------------- Date: 8/23/94 10:20 AM To: Ravender Goyal From: Syed Huq Received: by pdxml2.mentorg.com with SMTP;23 Aug 1994 10:20:43 U Received: from mgc.mentorg.com by newsgw.mentorg.com (8.6.4/CF5.22R) id NAA20549; Tue, 23 Aug 1994 13:11:27 -0400 Received: from vhdl.vhdl.org by mgc.mentorg.com with SMTP (16.6/15.5+MGC-TD 2.20) id AA24671; Tue, 23 Aug 94 10:12:22 -0700 Received: from gatekeeper.nsc.com by vhdl.vhdl.org (4.1/SMI-4.1/BARRNet) id AA25754; Tue, 23 Aug 94 10:00:32 PDT Received: from nsc.nsc.com by gatekeeper.nsc.com (5.65/fma-120691) with SMTP; id AA25651 for ibis@vhdl.org; Tue, 23 Aug 94 09:57:06 -0700 Received: from lightning.nsc.com by nsc.nsc.com (5.65/1.34) with SMTP id AA09392 for ibis@vhdl.org; Tue, 23 Aug 94 09:57:05 -0700 Received: from kural by rockie.nsc.com (4.1/SMI-4.1) id AA04666; Tue, 23 Aug 94 09:58:43 PDT Date: Tue, 23 Aug 94 09:58:42 PDT From: huq@rockie.nsc.com (Syed Huq) Message-Id: <9408231658.AA04666@rockie.nsc.com> To: ibis@vhdl.org Subject: IBIS - DIET - OMF Cc: cjfgsc@tevm2.nsc.com Hi, Recently I came across an article in Electronic Engineering Times about a Modeling standard called OMF(Open Model Forum). This forum uses Logic Modeling's Swift as an interface and they are a part of CFI(CAD Framework Initiative). OMF is trying to standardize it's methodology and has over 40 EDA, semi- conductor and model vendors as members. OMF's main goal is model inter operability, protection of IC vendors intellectual property... This to me seems very similar to IBIS. Also, I have been getting copied on the DIET(Die Information Exchange for Timing)mettings coming up. I thought the DIE forum references IBIS for Signal Integrity Analysis. Then what is this DIET ?? I am sure there are IBIS members who participate in both the OMF and DIET forums. How about making some comments about the key differences between all these forums.. Regards, Syed huq National Semiconductor From steffen@anacad.de Tue Aug 23 13:32:52 1994 Return-Path: Received: from mail.Germany.EU.net by vhdl.vhdl.org (4.1/SMI-4.1/BARRNet) id AA26840; Tue, 23 Aug 94 13:32:52 PDT Received: by mail.Germany.EU.net with UUCP (8.6.5:29/EUnetD-2.4.4.a) via EUnet id WAA26199; Tue, 23 Aug 1994 22:30:49 +0200 Received: from asterix.noname anacad.de by anacad.de (4.1/SMC-5.11) Date: Tue, 23 Aug 94 21:58:04 +0200 From: *** Steffen Rochel *** Message-Id: <9408231958.AA00545@anacad.de> To: ibis@vhdl.org Subject: ibis 2.0 BNF Content-Type: X-sun-attachment ---------- X-Sun-Data-Type: text X-Sun-Data-Description: text X-Sun-Data-Name: text X-Sun-Content-Lines: 8 Hi Bob, based on your work I improved the BNF for IBIS v2.0. I included also the BNF for the package model. I hope, that I covered most of the intentions from the spec, but I think some clearifications are necessary. Steffen Rochel Anacad EES ---------- X-Sun-Data-Type: default X-Sun-Data-Description: default X-Sun-Data-Name: ibis2_0.bnf X-Sun-Content-Lines: 333 // Remarks // comments starts with "//" // keyword are enclosed by '...' // a set is specified by { }, options are enclosed by [ ... ] // "|" defines an alternative ibisfile ::= ibisfileheader sections '[' 'end' ']' packagefile ::= packagefileheader packagedefinitionsections '[' 'end' ']' ibisfileheader ::= ibisversion ibisfilename fileversion fileheaderitems packagefileheader ::= ibisversion packagefilename fileversion fileheaderitems fileheaderitems ::= [ commentchar ] [ date ] [ source ] [ notes ] [ disclaimer ] [ copyright ] ibisversion ::= '[' 'ibis ver' ']' string commentchar ::= '[' 'comment char' ']' commentstring commentstring ::= comment_character '_char' comment_character ::= <|> | | <"> | <:> | <;> | <\<>| <\>>| <,> | <{> | <}> | <\'>| <\\>| <(> | <)> | <*> | <&> | | <@> | <#> | <$> | <%> | <^> | <~> | <\`> ibisfilename ::= '[' 'file name' ']' ibisfilenamestring ibisfilenamestring ::= string8 '.ibs' packagefilename ::= '[' 'file name' ']' packagefilenamestring packagefilenamestring ::= string8 '.pkg' fileversion ::= '[' 'file rev' ']' string date ::= '[' 'date' ']' string40 source ::= '[' 'source' ']' string40 notes ::= '[' 'notes' ']' string40 disclaimer ::= '[' 'disclaimer' ']' string40 copyright ::= '[' 'copyright' ']' string40 sections ::= componentdefinitionsection [ modeldefinitionsections ] [ packagedefinitionsection ] modeldefinitionsections ::= { modeldefinitionsection } packagedefinitionsections ::= { packagedefinitionsection } componentdefinitionsection ::= component manufacturer package pin [ package_model ] [ pin_mapping ] [ diff_pin ] component ::= '[' 'component' ']' string40 manufacturer ::= '[' 'manufacturer' ']' string40 package ::= '[' 'package' ']' package_rlc package_rlc ::= 'r_pkg' typ_min_max 'l_pkg' typ_min_max 'c_pkg' typ_min_max typ_min_max ::= real real_na real_na real_na ::= real | 'na' real_na9 ::= real9 | 'na' //pin_with_package_info pin ::= pin_wpi | pin_data pin_wpi ::= pin_header 'r_pin' 'l_pin' 'c_pin' pin_entry_set_wpi pin_data ::= pin_header pin_entry_set pin_header ::= '[' 'pin' ']' 'signal_name' 'model_name' pin_entry_set_wpi ::= pin_entry_wpi { pin_entry_wpi } pin_entry_set ::= pin_entry { pin_entry } pin_entry_wpi ::= pin_entry real_na9 real_na9 real_na9 pin_entry ::= pin_identifier signal_identifier [ model_identifier ] pin_identifier ::= string5 signal_identifier ::= string20 model_identifier ::= string20 | 'power' | 'gnd' | 'nc' package_model ::= '[' 'package model' ']' string40 pin_mapping ::= '[' 'pin mapping' ']' 'pulldown_ref' 'pullup_ref' 'gnd_clamp_ref' 'power_clamp_ref' pin_mapping_data_set pin_mapping_data_set ::= pin_mapping_data { pin_mapping_data } pin_mapping_data ::= string5 string15 string15 [ string15 string15 ] diff_pin ::= diff_pin_wr | diff_pin_data diff_pin_wr ::= diff_pin_header delay_range_name diff_pin_value_set_wr diff_pin_data ::= diff_pin_header diff_pin_value_set diff_pin_header ::= '[' 'diff_pin' ']' 'inv_pin' 'vdiff' 'tdelay_typ' delay_range_name ::= 'tdelay_min' 'tdelay_max' diff_pin_value_set ::= diff_pin_values { diff_pin_values } diff_pin_value_set_wr ::= diff_pin_values_wr { diff_pin_values_wr } diff_pin_values_wr ::= diff_pin_values real_na9 real_na9 diff_pin_values ::= string5 string5 real9 real_na9 modeldefinitionsection ::= '[' 'model' ']' model_name model model_name ::= string20 model ::= model_of_type_one | model_of_type_two | model_of_type_terminator model_of_type_one ::= modeltype_one modelentry_one model_of_type_two ::= modeltype_two modelentry_two model_of_type_terminator ::= modeltype_terminator modelentry_terminator modeltype_one ::= 'model_type' modeltype_one_identifier modeltype_one_identifier ::= 'input' | 'i/o' | 'i/o_open_drain' | 'i/o_open_sink' | 'i/o_open_source' | 'input_ecl' | 'i/o_ecl' modeltype_two ::= 'model_type' modeltype_two_identifier modeltype_two_identifier ::= '3-state' | 'open_sink' | 'open_drain' | 'open_source' | 'output' | 'output_ecl' modeltype_terminator ::= 'model_type' 'terminator' modelentry_one ::= c_comp vinl vinh modelentry modelentry_two ::= c_comp modelentry modelentry_terminator ::= c_comp modelentry modelentry ::= [ polarity ] [ enable ] [ vmeas ] [ cref ] [ rref ] [ vref ] [ temperature_range ] [ model_range ] [ pulldown ] [ pullup ] [ gndclamp ] [ powerclamp ] [ rpower ] [ rgnd ] [ ramp ] [ rac ] [ cac ] [ waveformtable ] model_range ::= voltage_range | model_refs | voltage_range model_refs model_refs ::= [ pullup_reference ] [ pulldown_reference ] [ gnd_clamp_reference ] [ power_clamp_reference ] c_comp ::= 'c_comp' typ_min_max polarity ::= 'polarity' [ 'non-inverting' | 'inverting' ] enable ::= 'enable' [ 'active-high' | 'active-low' ] vinl ::= 'vinl' '=' voltage_spec vinh ::= 'vinh' '=' voltage_spec vmeas ::= 'vmeas' '=' voltage_spec cref ::= 'cref' '=' capacitance_spec rref ::= 'rref' '=' resistance_spec vref ::= 'vref' '=' voltage_spec voltage_spec ::= real capacitance_spec ::= real resistance_spec ::= real temperature_range ::= '[' 'temperature range' ']' typ_min_max voltage_range ::= '[' 'voltage range' ']' typ_min_max pullup_reference ::= '[' 'pullup reference' ']' typ_min_max pulldown_reference ::= '[' 'pulldown reference' ']' typ_min_max power_clamp_reference ::= '[' 'power clamp reference' ']' typ_min_max gnd_clamp_reference ::= '[' 'gnd clamp reference' ']' typ_min_max pulldown ::= '[' 'pulldown' ']' videfinitions pullup ::= '[' 'pullup' ']' videfinitions gndclamp ::= '[' 'gnd_clamp' ']' videfinitions powerclamp ::= '[' 'power_clamp' ']' videfinitions rpower ::= '[' 'rpower' ']' typ_min_max rgnd ::= '[' 'rgnd' ']' typ_min_max videfinitions ::= videfinition { videfinition } videfinition ::= real typ_min_max ramp ::= '[' 'ramp' ']' { dvdtr | dvdtf } [ r_load ] dvdtr ::= 'dv/dt_r' typ_min_max_rate dvdtf ::= 'dv/dt_r' typ_min_max_rate r_load ::= 'r_load' '=' real typ_min_max_rate ::= rate [ rate | 'na' ] [ rate | 'na' ] rac ::= '[' 'rac' ']' typ_min_max cac ::= '[' 'cac' ']' typ_min_max waveformtable ::= { waveform_data } waveform_data ::= '[' 'rising waveform' | 'falling waveform' ']' waveform_header waveform_table waveform_header ::= r_fixture v_fixture [ c_fixture ] [ l_fixture ] [ r_dut ] [ l_dut ] [ c_dut ] r_fixture ::= 'r_fixture' '=' real v_fixture ::= 'v_fixture' '=' real c_fixture ::= 'c_fixture' '=' real l_fixture ::= 'l_fixture' '=' real r_dut ::= 'r_dut' '=' real l_dut ::= 'l_dut' '=' real c_dut ::= 'c_dut' '=' real waveform_table ::= { waveform_point } waveform_point ::= time_point typ_min_max time_point ::= real rate ::= real '/' real packagedefinitionsection ::= definepackage package_header package_description endpackage definepackage ::= '[' 'define package model' ']' string40 package_header ::= manufacturer oem description pin_number pin_names oem ::= '[' 'oem' ']' string40 description ::= '[' 'description' ']' string60 pin_number ::= '[' 'number of pins' ']' pos_integer pin_names ::= pin_name { pin_name } pin_name ::= string5 package_description ::= '[' 'model data' ']' model_body '[' 'end model data' ']' model_body ::= inductance_matrix capacitance_matrix [ resistance_matrix ] inductance_matrix ::= '[' 'indcuctance matrix' ']' matrix capacitance_matrix ::= '[' 'capacitance matrix' ']' matrix resistance_matrix ::= '[' 'resistance matrix' ']' matrix matrix ::= full_matrix | banded_matrix | sparse_matrix full_matrix ::= 'full matrix' matrix_line { matrix_line } banded_matrix ::= 'banded matrix' bandwith matrix_line { matrix_line } sparse_matrix ::= 'sparse matrix' matrix_line { matrix_line } bandwith ::= '[' 'bandwith' ']' pos_integer matrix_line ::= '[' 'row' ']' real { real } endpackage ::= '[' 'end package model' ']' real ::= [ unit ] real9 ::= unit ::=

| | | | | | { char } string5 ::= string8 ::= string15 ::= string20 ::= string40 ::= string60 ::= string ::= char ::= pos_integer ::= From Will_Hobbs@ccm2.jf.intel.com Tue Aug 23 15:08:44 1994 Return-Path: Received: from ormail.intel.com by vhdl.vhdl.org (4.1/SMI-4.1/BARRNet) id AA27273; Tue, 23 Aug 94 15:08:44 PDT Received: from relay.jf.intel.com by ormail.intel.com with smtp (Smail3.1.28.1 #12) id m0qd3xp-000MPrC; Tue, 23 Aug 94 15:05 PDT Received: from ccm.jf.intel.com by relay.jf.intel.com (Smail3.1.28.1 #2) id m0qd3xo-000tweC; Tue, 23 Aug 94 15:05 PDT Received: by ccm.jf.intel.com (ccmgate 3.0) Tue, 23 Aug 94 15:05:04 PST Date: Tue, 23 Aug 94 15:05:04 PST From: Will Hobbs Message-Id: <940823150504_2@ccm.jf.intel.com> To: Ravender_Goyal@pdxml1.mentorg.com, Steve_Sherwood@pdxml1.mentorg.com Cc: ibis@vhdl.org, huq@rockie.nsc.com Subject: Re[2]: IBIS - DIET - OMF Text item: Ravender, I already replied to Syed. I am forwarding Steve my mail too, to save him from repeating what has already been said. Will Reply to: RE>IBIS - DIET - OMF I am forwarding this mail to Steve Sherwood who is the chairperson for OMF. Steve, can you please enlighten IBISians about your efforts on OMF. Thanks - ravender -------------------------------------- Date: 8/23/94 10:20 AM To: Ravender Goyal From: Syed Huq Received: by pdxml2.mentorg.com with SMTP;23 Aug 1994 10:20:43 U Received: from mgc.mentorg.com by newsgw.mentorg.com (8.6.4/CF5.22R) id NAA20549; Tue, 23 Aug 1994 13:11:27 -0400 Received: from vhdl.vhdl.org by mgc.mentorg.com with SMTP (16.6/15.5+MGC-TD 2.20) id AA24671; Tue, 23 Aug 94 10:12:22 -0700 Received: from gatekeeper.nsc.com by vhdl.vhdl.org (4.1/SMI-4.1/BARRNet) id AA25754; Tue, 23 Aug 94 10:00:32 PDT Received: from nsc.nsc.com by gatekeeper.nsc.com (5.65/fma-120691) with SMTP; id AA25651 for ibis@vhdl.org; Tue, 23 Aug 94 09:57:06 -0700 Received: from lightning.nsc.com by nsc.nsc.com (5.65/1.34) with SMTP id AA09392 for ibis@vhdl.org; Tue, 23 Aug 94 09:57:05 -0700 Received: from kural by rockie.nsc.com (4.1/SMI-4.1) id AA04666; Tue, 23 Aug 94 09:58:43 PDT Date: Tue, 23 Aug 94 09:58:42 PDT From: huq@rockie.nsc.com (Syed Huq) Message-Id: <9408231658.AA04666@rockie.nsc.com> To: ibis@vhdl.org Subject: IBIS - DIET - OMF Cc: cjfgsc@tevm2.nsc.com Hi, Recently I came across an article in Electronic Engineering Times about a Modeling standard called OMF(Open Model Forum). This forum uses Logic Modeling's Swift as an interface and they are a part of CFI(CAD Framework Initiative). OMF is trying to standardize it's methodology and has over 40 EDA, semi- conductor and model vendors as members. OMF's main goal is model inter operability, protection of IC vendors intellectual property... This to me seems very similar to IBIS. Also, I have been getting copied on the DIET(Die Information Exchange for Timing)mettings coming up. I thought the DIE forum references IBIS for Signal Integrity Analysis. Then what is this DIET ?? I am sure there are IBIS members who participate in both the OMF and DIET forums. How about making some comments about the key differences between all these forums.. Regards, Syed huq National Semiconductor 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: ibis@vhdl.org, "Syed Huq" To: Steve_Sherwood@pdxml1.mentorg.com Subject: Re: IBIS - DIET - OMF From: "Ravender Goyal" Date: 23 Aug 1994 13:24:49 -0800 Message-Id: <199408232028.NAA17967@wv.mentorg.com> Received: from pdxml1.mentorg.com by wv.mentorg.com (8.6.8.1/CF5.22R) id NAA17967; Tue, 23 Aug 1994 13:28:25 -0700 Received: from wv.mentorg.com by newsgw.mentorg.com (8.6.4/CF5.22R) id QAA28018; Tue, 23 Aug 1994 16:27:29 -0400 Received: from newsgw.mentorg.com by vhdl.vhdl.org (4.1/SMI-4.1/BARRNet) id AA26835; Tue, 23 Aug 94 13:31:56 PDT Received: from vhdl.vhdl.org by hermes.intel.com (5.65/10.0i); Tue, 23 Aug 94 13 Received: from hermes by ichips.intel.com (5.64+/10.0i); Tue, 23 Aug 94 13:40:09 Received: from ichips.intel.com by relay.jf.intel.com with smtp (Smail3.1.28.1 #2) id m0qd2g4-000txfC; Tue, 23 Aug 94 13:42 PDT From paulf@eos.ncsu.edu Tue Aug 23 17:31:27 1994 Return-Path: Received: from c11059-364dan.ece.ncsu.edu by vhdl.vhdl.org (4.1/SMI-4.1/BARRNet) id AA28005; Tue, 23 Aug 94 17:31:27 PDT Received: by c11059-364dan.ece.ncsu.edu (5.65/Eos/C-U-09Sep93) id AA21216; Tue, 23 Aug 1994 20:27:58 -0400 From: paulf@eos.ncsu.edu Message-Id: <9408240027.AA21216@c11059-364dan.ece.ncsu.edu> To: si-list@android.ebay.sun.com, ibis@vhdl.org Subject: Signal Integrity Session at DAC-95? Date: Tue, 23 Aug 94 20:27:57 EDT Session Proposal for 1995 Design Automation Conference: Design for Signal Integrity =========================== or similar. Last year at the IBIS BOF meeting, it was suggested that a special topics session be organized for DAC on this topic. I am willing to try to coordinate such an effort. Who out there is in a position to contribute a paper to this session, please? A number of possibilities are possible: 1) More academic theoretical papers describing new algoirithms and methodolologies. 2) `Designer Track' type papers describing `DA system integration', `use of DA in design', `design methodology and proces's, `DA vendor partnering', `standards issues' etc. Please note that DAC requires the submission of a full paper and has a very high (3 out of 4) rejection rate. It would be great if we could coordinate a session with an SI emphasis. Please let me know your thoughts. Papers are due Oct. 7. Regards, Paul Franzon From Will_Hobbs@ccm2.jf.intel.com Tue Aug 23 18:16:26 1994 Return-Path: Received: from ormail.intel.com by vhdl.vhdl.org (4.1/SMI-4.1/BARRNet) id AA28228; Tue, 23 Aug 94 18:16:26 PDT Received: from relay.jf.intel.com by ormail.intel.com with smtp (Smail3.1.28.1 #12) id m0qd6td-000MNUC; Tue, 23 Aug 94 18:12 PDT Received: from ccm.jf.intel.com by relay.jf.intel.com (Smail3.1.28.1 #2) id m0qd6tc-000twcC; Tue, 23 Aug 94 18:12 PDT Received: by ccm.jf.intel.com (ccmgate 3.0) Tue, 23 Aug 94 18:12:56 PST Date: Tue, 23 Aug 94 18:12:56 PST From: Will Hobbs Message-Id: <940823181256_8@ccm.jf.intel.com> To: Arpad_Muranyi@ccm.fm.intel.com, ibis@vhdl.org Subject: Re: Voltage ranges Text item: Text_1 IBISers, This is possibly a nit, but "span" indicates to met that it has to cover _at least_ the stated range. Going beyond it is not precluded. Has anyone checked out how the parser handles greater ranges? Will Hobbs Intel Corp. Hi IBIS folks, I had an AR to find out how SPICE people feel about the "100 point limit". From the answers I received from three different SPICE simulation tool vendors I concluded that there is no need to limit the data to 100 points. That's all I want to say about this now, but we can discuss it in more detail on the next Open Forum meeting. Along the same lines, I would like to extend each I-V curve to cover the same voltage span. Currently the GND clamp and POWER clamp curves are limited to a smaller range than the pulldown and pullup curves. I see the need for this when there is a weak pullup (or pulldown) "resistor" in a buffer or receiver. The current understanding is that these kinds of "resistors" can be put into the 0 to 5V range of the GND clamp curve. However, putting a Vcc-relative pullup resistor into a ground relative GND clamp curve creates a bunch of problems. For this reason, it would be nice to be able to put the pullup "resistors" into the POWER clamp curve, but it's voltage range - as defined in ver1.1 (and 2.0) - does not provide room for it. The logical step would be to extend it's range to be the same as the GND clamp's range is. But then why not just make all of the ranges the same for simplicity sake? When I wrote about this before, some people responded that they view the specified ranges as minimum required ranges and it did not matter if I published wider ranges in my models. However, I looked up in the ver1.1 spec, and it says: "Points for each curve must span the voltages listed below" which means no more and no less. I am about to release a new set of models in which I will most likely violate the spec. by using exdended voltage ranges in some of the clamp curves. Since I do not want to get blamed for changing my mind all the time, I would like to hear what you, IBIS people think about releasing such models before I do so. I must admit that I am not one of those Godly people who can see into the future, so when I wrote ver1.1 I did not see this problem coming. Sincerely Arpad Muranyi Intel Corporation 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: Voltage ranges To: ibis@vhdl.org Message-Id: <940818112132_1@ccm.hf.intel.com> From: Arpad Muranyi Date: Thu, 18 Aug 94 11:21:32 PST Received: by ccm.hf.intel.com (ccmgate 3.0) Thu, 18 Aug 94 11:21:32 PST Received: from ccm.hf.intel.com by relay.jf.intel.com (Smail3.1.28.1 #2) id m0qbC5l-000tweC; Thu, 18 Aug 94 11:21 PDT Received: from relay.jf.intel.com by ormail.intel.com with smtp (Smail3.1.28.1 #12) id m0qbC5l-000MVXC; Thu, 18 Aug 94 11:21 PDT Received: from ormail.intel.com by vhdl.vhdl.org (4.1/SMI-4.1/BARRNet) id AA05746; Thu, 18 Aug 94 12:19:53 PDT Received: from vhdl.vhdl.org by hermes.intel.com (5.65/10.0i); Thu, 18 Aug 94 12 Received: from hermes by ichips.intel.com (5.64+/10.0i); Thu, 18 Aug 94 12:34:16 Received: from ichips.intel.com by relay.jf.intel.com with smtp (Smail3.1.28.1 #2) id m0qbDF5-000twcC; Thu, 18 Aug 94 12:35 PDT From Derrick_Duehren@ccm2.jf.intel.com Wed Aug 24 18:42:57 1994 Return-Path: Received: from ormail.intel.com by vhdl.vhdl.org (4.1/SMI-4.1/BARRNet) id AA08177; Wed, 24 Aug 94 18:42:57 PDT Received: from relay.jf.intel.com by ormail.intel.com with smtp (Smail3.1.28.1 #12) id m0qdTmo-000MP6C; Wed, 24 Aug 94 18:39 PDT Received: from ccm.hf.intel.com by relay.jf.intel.com (Smail3.1.28.1 #2) id m0qdTmo-000twcC; Wed, 24 Aug 94 18:39 PDT Received: by ccm.hf.intel.com (ccmgate 3.0) Wed, 24 Aug 94 18:39:25 PST Date: Wed, 24 Aug 94 18:39:25 PST From: Derrick Duehren Message-Id: <940824183925_2@ccm.hf.intel.com> To: IBIS@vhdl.org Subject: IBIS: How to order the Golden Parser v2.1 Text item: Text_1 To obtain ibis_chk version 2.1 source: A company may obtain source code for the 2.1 Golden Parser by submitting a request to: Conference Management Services 407 Chester Street Menlo Park, CA 94025 415-329-0510 415-324-3150 (fax) cms@cis.stanford.edu Enclose a check for $500.00 made out to IBIS. CMS will take care of notifying Randy Harr and/or Will Hobbs who will take care of distributing the source once it is available. Disclaimer: The version 2.1 IBIS Golden Parser is currently under development under the direction of the IBIS Open Forum. There is no guarantee implied in your license fee that the parser will be completed or successful. - Derrick Duehren Intel From Will_Hobbs@ccm2.jf.intel.com Wed Aug 24 18:44:58 1994 Return-Path: Received: from ormail.intel.com by vhdl.vhdl.org (4.1/SMI-4.1/BARRNet) id AA08192; Wed, 24 Aug 94 18:44:58 PDT Received: from relay.jf.intel.com by ormail.intel.com with smtp (Smail3.1.28.1 #12) id m0qdToC-000MOJC; Wed, 24 Aug 94 18:40 PDT Received: from ccm.jf.intel.com by relay.jf.intel.com (Smail3.1.28.1 #2) id m0qdToB-000twdC; Wed, 24 Aug 94 18:40 PDT Received: by ccm.jf.intel.com (ccmgate 3.0) Wed, 24 Aug 94 18:40:51 PST Date: Wed, 24 Aug 94 18:40:51 PST From: Will Hobbs Message-Id: <940824184051_6@ccm.jf.intel.com> To: paulf@eos.ncsu.edu, ibis@vhdl.org Subject: Re: Signal Integrity Session at DAC-95? Text item: Paul, Great idea. I'm all for it, though I doubt I could get a paper in by the deadline. Anyone else? Will Session Proposal for 1995 Design Automation Conference: Design for Signal Integrity =========================== or similar. Last year at the IBIS BOF meeting, it was suggested that a special topics session be organized for DAC on this topic. I am willing to try to coordinate such an effort. Who out there is in a position to contribute a paper to this session, please? A number of possibilities are possible: 1) More academic theoretical papers describing new algoirithms and methodolologies. 2) `Designer Track' type papers describing `DA system integration', `use of DA in design', `design methodology and proces's, `DA vendor partnering',`standards issues' etc. Please note that DAC requires the submission of a full paper and has a very high (3 out of 4) rejection rate. It would be great if we could coordinate a session with an SI emphasis. Please let me know your thoughts. Papers are due Oct. 7. Regards, Paul Franzon 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***. Date: Tue, 23 Aug 94 20:27:57 EDT Subject: Signal Integrity Session at DAC-95? To: si-list@android.ebay.sun.com, ibis@vhdl.org Message-Id: <9408240027.AA21216@c11059-364dan.ece.ncsu.edu> From: paulf@eos.ncsu.edu Received: by c11059-364dan.ece.ncsu.edu (5.65/Eos/C-U-09Sep93) id AA21216; Tue, 23 Aug 1994 20:27:58 -0400 Received: from c11059-364dan.ece.ncsu.edu by vhdl.vhdl.org (4.1/SMI-4.1/BARRNet) id AA28005; Tue, 23 Aug 94 17:31:27 PDT Received: from vhdl.vhdl.org by hermes.intel.com (5.65/10.0i); Tue, 23 Aug 94 17 Received: from hermes by ichips.intel.com (5.64+/10.0i); Tue, 23 Aug 94 17:36:38 Received: from ichips.intel.com by relay.jf.intel.com with smtp (Smail3.1.28.1 #2) id m0qd6My-000twdC; Tue, 23 Aug 94 17:39 PDT From Derrick_Duehren@ccm2.jf.intel.com Thu Aug 25 11:12:52 1994 Return-Path: Received: from ormail.intel.com by vhdl.vhdl.org (4.1/SMI-4.1/BARRNet) id AA15877; Thu, 25 Aug 94 11:12:52 PDT Received: from relay.jf.intel.com by ormail.intel.com with smtp (Smail3.1.28.1 #12) id m0qdjEm-000MPtC; Thu, 25 Aug 94 11:09 PDT Received: from ccm.hf.intel.com by relay.jf.intel.com (Smail3.1.28.1 #2) id m0qdjEl-000twjC; Thu, 25 Aug 94 11:09 PDT Received: by ccm.hf.intel.com (ccmgate 3.0) Thu, 25 Aug 94 11:09:19 PST Date: Thu, 25 Aug 94 11:09:19 PST From: Derrick Duehren Message-Id: <940825110919_1@ccm.hf.intel.com> To: IBIS@vhdl.org Subject: IBIS 8/26/94 Meeting Agenda Text item: Text_1 IBIS Open Forum Meeting Agenda for 8/26/94 Bridge: Res: (415) 904-8944 #809164 All meetings are 8:00 AM to 10:00 AM PDT (15:00 to 17:00 UTC). When you call into the meeting, ask for the IBIS Open Forum hosted by Will Hobbs and give the reservation number. 8:00 Check-in, Intros, Announcements Hobbs - Intros of new IBIS participants - Review of previous meeting's minutes - Miscellany/announcements/treasurer's report - Opens for new issues - Press updates - New models available 8:20 Progress toward enlisting new IC vendors All Golden Parser, 2.1 Hobbs Timing the release of 2.1 models Hobbs IBIS Librarian Powell Standards body affiliation (EIA) Hobbs ** VOTE TO BE TAKEN ** Spice-to-IBIS converter Ross 2.0 BNF Rochel 1995 Design Automation Conference Franzon 9:00 Pending BIRD 17, Number of Points Ross Pending Bird 19, V_fixture sub-keyword Ross Voltage range "span" Hobbs, Muranyi, Ross 9:55 Wrap-up, next meeting plans Hobbs From 73053.721@compuserve.com Fri Aug 26 13:40:17 1994 Return-Path: <73053.721@compuserve.com> Received: from dub-img-2.compuserve.com by vhdl.vhdl.org (4.1/SMI-4.1/BARRNet) id AA00849; Fri, 26 Aug 94 13:40:17 PDT Received: from localhost by dub-img-2.compuserve.com (8.6.4/5.940406sam) id QAA22739; Fri, 26 Aug 1994 16:36:39 -0400 Date: 26 Aug 94 16:33:51 EDT From: Paul Munsey <73053.721@compuserve.com> To: IBIS Reflector Subject: Golden Parser 2.0 Message-Id: <940826203350_73053.721_GHB76-1@CompuServe.COM> IBIS Members, I'm sorry to have missed this morning's meeting, but thought I could at least send an update through the mail. Ron Neville and I are are moving forward. We have most of the data structure figured out, but are still ironing out a few wrinkles. I, for the most part, just need to package it all together into one file so I can mail it out for those who are interested in looking at it. At the same time we are also progessing with the coding in the areas that we have well defined. It is proving very beneficial to have 2 people working on this project, sharing ideas, and coming to an understanding of the best methods and design for the parser. I do think we're behind where we would like to be at this time, but we are still targeting the end of September. The internal design is changing some from V1.1 to accomodate the requirements and better fit the V2.0 and future enhancements. Paul Munsey From paulf@eos.ncsu.edu Fri Aug 26 15:25:43 1994 Return-Path: Received: from c11059-364dan.ece.ncsu.edu by vhdl.vhdl.org (4.1/SMI-4.1/BARRNet) id AA01778; Fri, 26 Aug 94 15:25:43 PDT Received: by c11059-364dan.ece.ncsu.edu (5.65/Eos/C-U-09Sep93) id AA29405; Fri, 26 Aug 1994 18:22:14 -0400 From: paulf@eos.ncsu.edu Message-Id: <9408262222.AA29405@c11059-364dan.ece.ncsu.edu> To: ibis@vhdl.org Subject: DAC Session Date: Fri, 26 Aug 94 18:22:13 EDT Sorry, I could not sit in on this morning's meeting. What came of the DAC session discussion, if there was one please? Thanks, Paul From uunet!qdt.com!jonp@uunet.uu.net Fri Aug 26 16:29:21 1994 Return-Path: Received: from relay3.UU.NET by vhdl.vhdl.org (4.1/SMI-4.1/BARRNet) id AA02200; Fri, 26 Aug 94 16:29:21 PDT Received: from uucp1.UU.NET by relay3.UU.NET with SMTP id QQxerl20181; Fri, 26 Aug 1994 19:23:14 -0400 Received: from qdt.UUCP by uucp1.UU.NET with UUCP/RMAIL ; Fri, 26 Aug 1994 19:23:00 -0400 Received: from hal.qdt.com by qdt.com (4.1/SMI-4.1) id AA01167; Fri, 26 Aug 94 15:42:12 PDT Received: from qdt.com by hal.qdt.com (4.1/SMI-4.1) id AA20814; Fri, 26 Aug 94 15:40:06 PDT Received: from uucp7.UU.NET by relay3.UU.NET with SMTP id QQxere11116; Fri, 26 Aug 1994 17:41:31 -0400 Received: from qdt.UUCP by uucp7.UU.NET with UUCP/RMAIL ; Fri, 26 Aug 1994 17:41:41 -0400 Received: from hal.qdt.com by qdt.com (4.1/SMI-4.1) id AA00911; Fri, 26 Aug 94 11:25:32 PDT Received: from f14.qdt.com by hal.qdt.com (4.1/SMI-4.1) id AA20297; Fri, 26 Aug 94 11:23:25 PDT Date: Fri, 26 Aug 94 11:23:25 PDT From: uunet!qdt.com!jonp@uunet.uu.net (Jon Powell) Message-Id: <9408261823.AA20297@hal.qdt.com> Received: by f14.qdt.com (4.1/SMI-4.1) id AA02022; Fri, 26 Aug 94 11:23:12 PDT To: uunet!uunet!ccm2.jf.intel.com!Derrick_Duehren@uunet.uu.net Cc: uunet!uunet!vhdl.org!IBIS@uunet.uu.net In-Reply-To: Derrick Duehren's message of Thu, 25 Aug 94 11:09:19 PST <940825110919_1@ccm.hf.intel.com> Subject: IBIS data at VHDL.ORG Derrick and others, The changes at vhdl seem to have changed the access to the ibis on line database. I can no longer log in as "guest" or "anonymous" at the new phone number (or the old). Does anyone know the status or the new guest login id etc? jonp@qdt.com jon powell From speters@ichips.intel.com Fri Aug 26 16:58:42 1994 Return-Path: Received: from hermes.intel.com by vhdl.vhdl.org (4.1/SMI-4.1/BARRNet) id AA02421; Fri, 26 Aug 94 16:58:42 PDT Received: from [134.134.50.200] by hermes.intel.com (5.65/10.0i); Fri, 26 Aug 94 16:53:42 -0700 Received: from xtg801 by ichips.intel.com (5.64+/10.0i); Fri, 26 Aug 94 16:50:09 -0700 Received: from localhost by xtg801.intel.com (4.1/10.0i); Fri, 26 Aug 94 16:53:30 PDT Message-Id: <9408262353.AA19107@xtg801.intel.com> To: ibis@vhdl.org Subject: IBIS data at VHDL.ORG Date: Fri, 26 Aug 1994 16:53:28 -0700 From: Stephen Peters Hello Jon and others: I can no longer FTP to vhdl.org either... the indication is that the server is down. My guess is that they are having machine(hardware) problems. Stephen Peters Intel Corp. ----------------- Derrick and others, The changes at vhdl seem to have changed the access to the ibis on line database. I can no longer log in as "guest" or "anonymous" at the new phone number (or the old). Does anyone know the status or the new guest login id etc? jonp@qdt.com jon powell From Will_Hobbs@ccm2.jf.intel.com Fri Aug 26 17:39:03 1994 Return-Path: Received: from relay2.UU.NET by vhdl.vhdl.org (4.1/SMI-4.1/BARRNet) id AA02697; Fri, 26 Aug 94 17:39:03 PDT Received: from ormail.intel.com by relay2.UU.NET with SMTP id QQxerq26353; Fri, 26 Aug 1994 20:35:34 -0400 Received: from relay.jf.intel.com by ormail.intel.com with smtp (Smail3.1.28.1 #12) id m0qeBjU-000MO7C; Fri, 26 Aug 94 17:34 PDT Received: from ccm.jf.intel.com by relay.jf.intel.com (Smail3.1.28.1 #2) id m0qeBjU-000twdC; Fri, 26 Aug 94 17:34 PDT Received: by ccm.jf.intel.com (ccmgate 3.0) Fri, 26 Aug 94 17:34:56 PST Date: Fri, 26 Aug 94 17:34:56 PST From: Will Hobbs Message-Id: <940826173456_1@ccm.jf.intel.com> To: Derrick_Duehren@ccm2.jf.intel.com, billd@reprise.com, jonp%qdt.com%uunet@uunet.uu.net Cc: uunet!uunet!vhdl.org!IBIS@uunet.uu.net Subject: Re: IBIS data at VHDL.ORG Text item: Jon, I don't know, but since Bill den Beste is the new administrator, I am forwarding this on to him and copying Randy Harr. Will Derrick and others, The changes at vhdl seem to have changed the access to the ibis on line database. I can no longer log in as "guest" or "anonymous" at the new phone number (or the old). Does anyone know the status or the new guest login id etc? jonp@qdt.com jon powell 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: IBIS data at VHDL.ORG In-Reply-To: Derrick Duehren's message of Thu, 25 Aug 94 11:09:19 PST <940825110 Cc: uunet!uunet!vhdl.org!IBIS@uunet.uu.net To: uunet!uunet!ccm2.jf.intel.com!Derrick_Duehren@uunet.uu.net Received: by f14.qdt.com (4.1/SMI-4.1) id AA02022; Fri, 26 Aug 94 11:23:12 PDT Message-Id: <9408261823.AA20297@hal.qdt.com> From: uunet!qdt.com!jonp@uunet.uu.net (Jon Powell) Date: Fri, 26 Aug 94 11:23:25 PDT Received: from f14.qdt.com by hal.qdt.com (4.1/SMI-4.1) id AA20297; Fri, 26 Aug 94 11:23:25 PDT Received: from hal.qdt.com by qdt.com (4.1/SMI-4.1) id AA00911; Fri, 26 Aug 94 11:25:32 PDT Received: from qdt.UUCP by uucp7.UU.NET with UUCP/RMAIL ; Fri, 26 Aug 1994 17:41:41 -0400 Received: from uucp7.UU.NET by relay3.UU.NET with SMTP id QQxere11116; Fri, 26 Aug 1994 17:41:31 -0400 Received: from qdt.com by hal.qdt.com (4.1/SMI-4.1) id AA20814; Fri, 26 Aug 94 15:40:06 PDT Received: from hal.qdt.com by qdt.com (4.1/SMI-4.1) id AA01167; Fri, 26 Aug 94 15:42:12 PDT Received: from qdt.UUCP by uucp1.UU.NET with UUCP/RMAIL ; Fri, 26 Aug 1994 19:23:00 -0400 Received: from uucp1.UU.NET by relay3.UU.NET with SMTP id QQxerl20181; Fri, 26 Aug 1994 19:23:14 -0400 Received: from relay3.UU.NET by vhdl.vhdl.org (4.1/SMI-4.1/BARRNet) id AA02200; Fri, 26 Aug 94 16:29:21 PDT Received: from vhdl.vhdl.org by hermes.intel.com (5.65/10.0i); Fri, 26 Aug 94 16 Received: from hermes by ichips.intel.com (5.64+/10.0i); Fri, 26 Aug 94 16:36:28 Received: from ichips.intel.com by relay.jf.intel.com with smtp (Smail3.1.28.1 #2) id m0qeAsd-000twdC; Fri, 26 Aug 94 16:40 PDT From uunet!qdt.com!jonp@uunet.uu.net Fri Aug 26 19:20:33 1994 Return-Path: Received: from relay3.UU.NET by vhdl.vhdl.org (4.1/SMI-4.1/BARRNet) id AA03312; Fri, 26 Aug 94 19:20:33 PDT Received: from uucp1.UU.NET by relay3.UU.NET with SMTP id QQxerx29527; Fri, 26 Aug 1994 22:17:00 -0400 Received: from qdt.UUCP by uucp1.UU.NET with UUCP/RMAIL ; Fri, 26 Aug 1994 22:16:44 -0400 Received: from hal.qdt.com by qdt.com (4.1/SMI-4.1) id AA01392; Fri, 26 Aug 94 18:11:32 PDT Received: from qdt.com by hal.qdt.com (4.1/SMI-4.1) id AA21215; Fri, 26 Aug 94 18:09:26 PDT Received: from uucp1.UU.NET by relay3.UU.NET with SMTP id QQxerr24960; Fri, 26 Aug 1994 20:45:23 -0400 Received: from qdt.UUCP by uucp1.UU.NET with UUCP/RMAIL ; Fri, 26 Aug 1994 20:45:08 -0400 Received: from hal.qdt.com by qdt.com (4.1/SMI-4.1) id AA01297; Fri, 26 Aug 94 16:38:50 PDT Received: from f14.qdt.com by hal.qdt.com (4.1/SMI-4.1) id AA20997; Fri, 26 Aug 94 16:36:44 PDT Date: Fri, 26 Aug 94 16:36:44 PDT From: uunet!qdt.com!jonp@uunet.uu.net (Jon Powell) Message-Id: <9408262336.AA20997@hal.qdt.com> Received: by f14.qdt.com (4.1/SMI-4.1) id AA03181; Fri, 26 Aug 94 16:36:31 PDT To: uunet!uunet!eos.ncsu.edu!paulf@uunet.uu.net Cc: uunet!uunet!vhdl.org!ibis@uunet.uu.net In-Reply-To: uunet!eos.ncsu.edu!paulf's message of Fri, 26 Aug 94 18:22:13 EDT <9408262222.AA29405@c11059-364dan.ece.ncsu.edu> Subject: DAC Session Paul, I had the following question for you: How many papers need to be accepted for there to be a session? Given that, how many papers do you think need to be written? jonp From randyh@Synopsys.COM Mon Aug 29 12:14:21 1994 Return-Path: Received: from chronos.synopsys.com by vhdl.vhdl.org (4.1/SMI-4.1/BARRNet) id AA04877; Mon, 29 Aug 94 12:14:21 PDT Received: from gaea.synopsys.com by chronos.synopsys.com with SMTP id AA11329 (5.65c/IDA-1.4.4); Mon, 29 Aug 1994 12:09:26 -0700 Received: from clotho.synopsys.com by gaea.synopsys.com with SMTP id AA23132 (5.65c/IDA-1.4.4); Mon, 29 Aug 1994 12:09:25 -0700 Received: from tonga.synopsys.com (tonga.synopsys.com [146.225.82.16]) by clotho.synopsys.com (8.6.9/8.6.9) with SMTP id MAA12239; Mon, 29 Aug 1994 12:09:24 -0700 Date: Mon, 29 Aug 1994 12:09:24 -0700 Message-Id: <199408291909.MAA12239@clotho.synopsys.com> X-Sender: randyh@engr.synopsys.com Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii" To: jonp@qdt.com (Jon Powell), Derrick_Duehren@ccm2.jf.intel.com From: randyh@Synopsys.COM (Randolph E. "Randy" Harr) Subject: Re: IBIS data at VHDL.ORG Cc: IBIS@vhdl.org, group-sysops@vhdl.org X-Mailer: There were a number of messages from you and others on the IBIS reflector. FTP was not available (due to an error on my part; see what happens when you get management involved!) until this morning. Thank you for pointing that out. We are still having a configuration problem with the guest/anonymous dial-in accounts in that the password is being prompted for twice. Simply hit the return/enter key after the first password prompt and you will proceed as normal. We are trying to resolve the problem. Normal account dial-in is normal. At 11:23 AM 8/26/94 PDT, Jon Powell wrote: >Derrick and others, > >The changes at vhdl seem to have changed the access to the ibis on line >database. I can no longer log in as "guest" or "anonymous" at the new >phone number (or the old). Does anyone know the status or the new guest >login id etc? > >jonp@qdt.com >jon powell > > > > > Randolph E. (Randy) Harr Till 31 August: On 1 Sep: --------------------------------------- ------------------------------------ Senior Scientist and Program Manager Senior Research Associate Dept of EE, CIS Logic Modeling Group, Synopsys Inc. Stanford University randyh@synopsys.com, (415)694-1835(o) rharr@mojave.stanford.edu 415-725-3723 (msg) From randyh@Synopsys.COM Mon Aug 29 21:26:04 1994 Return-Path: Received: from chronos.synopsys.com by vhdl.vhdl.org (4.1/SMI-4.1/BARRNet) id AA09048; Mon, 29 Aug 94 21:26:04 PDT Received: from gaea.synopsys.com by chronos.synopsys.com with SMTP id AA22028 (5.65c/IDA-1.4.4); Mon, 29 Aug 1994 21:22:26 -0700 Received: from clotho.synopsys.com by gaea.synopsys.com with SMTP id AA25393 (5.65c/IDA-1.4.4); Mon, 29 Aug 1994 21:22:24 -0700 Received: from tonga.synopsys.com (tonga.synopsys.com [146.225.82.16]) by clotho.synopsys.com (8.6.9/8.6.9) with SMTP id VAA22158; Mon, 29 Aug 1994 21:22:22 -0700 Date: Mon, 29 Aug 1994 21:22:22 -0700 Message-Id: <199408300422.VAA22158@clotho.synopsys.com> X-Sender: randyh@engr.synopsys.com (Unverified) Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii" To: die@vhdl.org From: randyh@Synopsys.COM (Randolph E. "Randy" Harr) Subject: Upcoming DIE workshop and 1994 activities Cc: ibis@vhdl.org X-Mailer: For those of you not aware yet, I have personally decided to take an excellent opportunity for managing research at Stanford University. But this early departure leaves many important issues and features yet to be finished in the developing DIE format effort. Therefore, to make sure the work does not fall by the wayside, Logic Modeling Group has been searching for the right "funded" person to carry the torch forward for the fledgling DIE Industry Group. After considering many options, Bill den Beste and his associates were selected to complete the balance of funded activities I had previously been directing in the DIE format standards arena. Through our previous experience with him, we feel he will be able to quickly pick up and finish the charge to getting the DIE format to a useful, industry standard. This is already evident in Bill's ability to get the preliminary parser out in time for the next workshop after only coming on-board 1 August. I have been working with Bill over the past month or so transferring the knowledge gained and status of activities to him and his group. This includes the limited support we have lent to the IBIS Open Forum. Please help me in supporting Bill (and Larry Saunders still) as the funded resources to make the DIE format the adopted, industry success that we all worked for. Although I am unable to attend the next workshop myself due to a scheduling conflict, I still plan to stay actively involved and assist the people and process for DIE standardization to completion. Also, I will continue to oversee the overall management and development of the vhdl.org services. If you have any questions, save them for the workshop or direct them to Bill (billd@reprise.com), Larry Saunders (lfs@synopsys.com) or myself (rharr@mojave.stanford.edu). Also, Bill Lattin (billl@lmc.synopsys.com) will be tracking the overall activities for Logic Modeling Group in my absence and can be contacted for further information. Thanks for all your support over the past one and a half years to make the current effort the success it is. And many thanks to Logic Modeling Group, Synopsys Inc. and especially nCHIP for providing a great environment within which to foster the DIE format development. I look forward to still working with everyone in my new role at Stanford. Randolph E. (Randy) Harr Till 31 August: On 1 Sep: --------------------------------------- ------------------------------------ Senior Scientist and Program Manager Senior Research Associate Dept of EE, CIS Logic Modeling Group, Synopsys Inc. Stanford University randyh@synopsys.com, (415)694-1835(o) rharr@mojave.stanford.edu 415-725-3723 (msg) From bob@icx.com Tue Aug 30 10:19:45 1994 Return-Path: Received: from uu4.psi.com by vhdl.vhdl.org (4.1/SMI-4.1/BARRNet) id AA18267; Tue, 30 Aug 94 10:19:45 PDT Received: by uu4.psi.com (5.65b/4.0.071791-PSI/PSINet) via UUCP; id AA15111 for ; Tue, 30 Aug 94 13:09:34 -0400 Date: Tue, 30 Aug 94 09:58:46 PDT From: bob@icx.com ( Bob Ross) Received: by icx.com (4.1/3.2.083191-Interconnectix Inc.) id AA06088; Tue, 30 Aug 94 09:58:46 PDT Message-Id: <9408301658.AA06088@icx.com> To: ibis@vhdl.org Subject: Thanks, Randy To Randy Harr: I just want to express my appreciation to you for your contributions to the IBIS development effort including getting us connected with vhdl.org and giving us valuable guidance concerning the standardization process. Best wishes to you, and please stay in touch. Bob Ross, Interconnectix, Inc. From 71436.1314@compuserve.com Tue Aug 30 16:14:56 1994 Return-Path: <71436.1314@compuserve.com> Received: from arl-img-1.compuserve.com by vhdl.vhdl.org (4.1/SMI-4.1/BARRNet) id AA20618; Tue, 30 Aug 94 16:14:56 PDT Received: from localhost by arl-img-1.compuserve.com (8.6.4/5.940406sam) id TAA15914; Tue, 30 Aug 1994 19:11:20 -0400 Date: 30 Aug 94 17:56:06 EDT From: Kellee Crisafulli <71436.1314@compuserve.com> To: IBIS ALL Subject: Moving to Stanford, From: Kellee Crisafulli, HyperLynx Message-Id: <940830215606_71436.1314_HHB67-1@CompuServe.COM> To Randy Harr: Thankyou for your contributions to the IBIS development efforts. Best wishes with your new direction at Stanford. Please keep us posted if anything interesting turns up. Kellee Crisafulli, HyperLynx, Inc. From Derrick_Duehren@ccm2.jf.intel.com Tue Aug 30 17:58:37 1994 Return-Path: Received: from ormail.intel.com by vhdl.vhdl.org (4.1/SMI-4.1/BARRNet) id AA21295; Tue, 30 Aug 94 17:58:37 PDT Received: from relay.jf.intel.com by ormail.intel.com with smtp (Smail3.1.28.1 #12) id m0qfdx9-000MNiC; Tue, 30 Aug 94 17:55 PDT Received: from ccm.jf.intel.com by relay.jf.intel.com (Smail3.1.28.1 #2) id m0qfdx9-000twdC; Tue, 30 Aug 94 17:55 PDT Received: by ccm.jf.intel.com (ccmgate 3.0) Tue, 30 Aug 94 17:55:03 PST Date: Tue, 30 Aug 94 17:55:03 PST From: Derrick Duehren Message-Id: <940830175503_2@ccm.jf.intel.com> To: ibis@vhdl.org Subject: Re: Thanks, Randy Randy, Here, here. We'll have a cake for you at our 9/16/94 meeting! :-) - Derrick ______________________________ Reply Separator _________________________________ Subject: Thanks, Randy Author: bob@icx.com at SMTPGATE Date: 8/30/94 10:43 AM To Randy Harr: I just want to express my appreciation to you for your contributions to the IBIS development effort including getting us connected with vhdl.org and giving us valuable guidance concerning the standardization process. Best wishes to you, and please stay in touch. Bob Ross, Interconnectix, Inc. From Will_Hobbs@ccm2.jf.intel.com Wed Aug 31 08:35:57 1994 Return-Path: Received: from ormail.intel.com by vhdl.vhdl.org (4.1/SMI-4.1/BARRNet) id AA08985; Wed, 31 Aug 94 08:35:57 PDT Received: from relay.jf.intel.com by ormail.intel.com with smtp (Smail3.1.28.1 #12) id m0qfre5-000MOAC; Wed, 31 Aug 94 08:32 PDT Received: from ccm.jf.intel.com by relay.jf.intel.com (Smail3.1.28.1 #2) id m0qfre5-000twfC; Wed, 31 Aug 94 08:32 PDT Received: by ccm.jf.intel.com (ccmgate 3.0) Wed, 31 Aug 94 08:32:15 PST Date: Wed, 31 Aug 94 08:32:15 PST From: Will Hobbs Message-Id: <940831083215_4@ccm.jf.intel.com> To: Derrick_Duehren@ccm2.jf.intel.com, ibis@vhdl.org Subject: Re[2]: Thanks, Randy Text item: Randy, I've already sent mail to you personally thanking you for all your help, but I would like to add my public recognition of your efforts to this chain letter. You were responsible for setting up the reflector, which has enabled the forum to communicate easily and effectively; I used the IBIS reflector as an example for the Open Model Forum to emulate in establishing its communication capabilities, to good effect. You also implemented the ibis structure on vhdl.org and maintained the mailing list and directories. You linked us up with CMS to establish our bank account, and you made our connection with EIA. You also added weight to the IBIS efforts through your DIE activities and gave us good information and advice at a number of junctures in the past 16 months. The significance of your contributions cannot be underestimated. On behalf of everyone in the IBIS Open Forum, I wish you the best of luck in your new position. I have no doubt you will do well. Will Hobbs Intel Corp., and Chairperson, IBIS Open Forum Randy, Here, here. We'll have a cake for you at our 9/16/94 meeting! :-) - Derrick ______________________________ Reply Separator _________________________________ Subject: Thanks, Randy Author: bob@icx.com at SMTPGATE Date: 8/30/94 10:43 AM To Randy Harr: I just want to express my appreciation to you for your contributions to the IBIS development effort including getting us connected with vhdl.org and giving us valuable guidance concerning the standardization process. Best wishes to you, and please stay in touch. Bob Ross, Interconnectix, Inc. 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: Thanks, Randy To: ibis@vhdl.org Message-Id: <940830175503_2@ccm.jf.intel.com> From: Derrick Duehren Date: Tue, 30 Aug 94 17:55:03 PST Received: by ccm.jf.intel.com (ccmgate 3.0) Tue, 30 Aug 94 17:55:03 PST Received: from ccm.jf.intel.com by relay.jf.intel.com (Smail3.1.28.1 #2) id m0qfdx9-000twdC; Tue, 30 Aug 94 17:55 PDT Received: from relay.jf.intel.com by ormail.intel.com with smtp (Smail3.1.28.1 #12) id m0qfdx9-000MNiC; Tue, 30 Aug 94 17:55 PDT Received: from ormail.intel.com by vhdl.vhdl.org (4.1/SMI-4.1/BARRNet) id AA21295; Tue, 30 Aug 94 17:58:37 PDT Received: from vhdl.vhdl.org by hermes.intel.com (5.65/10.0i); Tue, 30 Aug 94 18 Received: from hermes by ichips.intel.com (5.64+/10.0i); Tue, 30 Aug 94 17:58:26 Received: from ichips.intel.com by relay.jf.intel.com with smtp (Smail3.1.28.1 #2) id m0qfe4u-000tweC; Tue, 30 Aug 94 18:03 PDT From Will_Hobbs@ccm2.jf.intel.com Wed Aug 31 08:44:03 1994 Return-Path: Received: from ormail.intel.com by vhdl.vhdl.org (4.1/SMI-4.1/BARRNet) id AA09009; Wed, 31 Aug 94 08:44:03 PDT Received: from relay.jf.intel.com by ormail.intel.com with smtp (Smail3.1.28.1 #12) id m0qfrlW-000MO6C; Wed, 31 Aug 94 08:39 PDT Received: from ccm.jf.intel.com by relay.jf.intel.com (Smail3.1.28.1 #2) id m0qfrlW-000twcC; Wed, 31 Aug 94 08:39 PDT Received: by ccm.jf.intel.com (ccmgate 3.0) Wed, 31 Aug 94 08:39:58 PST Date: Wed, 31 Aug 94 08:39:58 PST From: Will Hobbs Message-Id: <940831083958_5@ccm.jf.intel.com> To: paulf@eos.ncsu.edu, ibis@vhdl.org Subject: Re: DAC Session Text item: Paul, As Jon Powell stated, there were several concerns: You said that typically 3 of 4 papers are rejected. If, as we surmised, we needed at least 3 accepted papers to have a session, does that mean the forum members need to generate 12 papers in order for anyone to get to present? That's a fairly big disincentive. There was a general feeling that a DAC session would be worthwhile, but with products to deliver, many of us don't want to spend valuable time in the next month writing a paper if there is only a small likelihood of it going anywhere. How many papers does it take to reach critical mass, or is that an irrelevant question? Will Sorry, I could not sit in on this morning's meeting. What came of the DAC session discussion, if there was one please? Thanks, Paul 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***. Date: Fri, 26 Aug 94 18:22:13 EDT Subject: DAC Session To: ibis@vhdl.org Message-Id: <9408262222.AA29405@c11059-364dan.ece.ncsu.edu> From: paulf@eos.ncsu.edu Received: by c11059-364dan.ece.ncsu.edu (5.65/Eos/C-U-09Sep93) id AA29405; Fri, 26 Aug 1994 18:22:14 -0400 Received: from c11059-364dan.ece.ncsu.edu by vhdl.vhdl.org (4.1/SMI-4.1/BARRNet) id AA01778; Fri, 26 Aug 94 15:25:43 PDT Received: from vhdl.vhdl.org by aurora.intel.com (5.65/10.0i); Fri, 26 Aug 94 15 Received: from aurora by ichips.intel.com (5.64+/10.0i); Fri, 26 Aug 94 15:30:44 Received: from ichips.intel.com by relay.jf.intel.com with smtp (Smail3.1.28.1 #2) id m0qe9qa-000twdC; Fri, 26 Aug 94 15:34 PDT From randyh@Synopsys.COM Wed Aug 31 10:59:57 1994 Return-Path: Received: from chronos.synopsys.com by vhdl.vhdl.org (4.1/SMI-4.1/BARRNet) id AA09927; Wed, 31 Aug 94 10:59:57 PDT Received: from gaea.synopsys.com by chronos.synopsys.com with SMTP id AA25700 (5.65c/IDA-1.4.4 for ); Wed, 31 Aug 1994 10:56:27 -0700 Received: from clotho.synopsys.com by gaea.synopsys.com with SMTP id AA12193 (5.65c/IDA-1.4.4 for ); Wed, 31 Aug 1994 10:56:25 -0700 Received: from tonga.synopsys.com (tonga.synopsys.com [146.225.82.16]) by clotho.synopsys.com (8.6.9/8.6.9) with SMTP id KAA19672; Wed, 31 Aug 1994 10:56:24 -0700 Date: Wed, 31 Aug 1994 10:56:24 -0700 Message-Id: <199408311756.KAA19672@clotho.synopsys.com> X-Sender: randyh@engr.synopsys.com Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii" To: keutzer@Synopsys.COM, raul@Synopsys.COM, rudell@Synopsys.COM From: randyh@Synopsys.COM (Randolph E. "Randy" Harr) Subject: Re: DAC Session Cc: ibis@vhdl.org X-Mailer: When there is a special session being proposed, the session organizer is given leeway to bring "invited papers" and speakers. The normal blind review process for the panel or paper session is modified. At least this is the way it was up until a few years ago. I will pass the message on to Kurt Keutzer, Raul Camposano, and Rich Rudell of our company (we keep hiring anybody on the DAC program committee it seems!) -- all who were on last years program committee from what I recall and who may be able to comment. Raul, Rich and Kurt: It was suggested by Paul Franzone of NCState that we propose a special DAC session on IBIS and signal integrity problems and modeling. Given the exposure at this years DAC in terms of the exhibit floor it seemed appropriate. Can any of you advise the IBIS committee (ibis@vhdl.org) about the procedures for trying to organize such a session. > >Text item: > >Paul, > >As Jon Powell stated, there were several concerns: > >You said that typically 3 of 4 papers are rejected. If, as we surmised, we >needed at least 3 accepted papers to have a session, does that mean the forum >members need to generate 12 papers in order for anyone to get to present? >That's a fairly big disincentive. > >There was a general feeling that a DAC session would be worthwhile, but with >products to deliver, many of us don't want to spend valuable time in the next >month writing a paper if there is only a small likelihood of it going anywhere. >How many papers does it take to reach critical mass, or is that an irrelevant >question? > >Will > >Sorry, I could not sit in on this morning's meeting. > >What came of the DAC session discussion, if there >was one please? > >Thanks, > >Paul > Randolph E. (Randy) Harr Till 31 August: On 1 Sep: --------------------------------------- ------------------------------------ Senior Scientist and Program Manager Senior Research Associate Dept of EE, CIS Logic Modeling Group, Synopsys Inc. Stanford University randyh@synopsys.com, (415)694-1835(o) rharr@mojave.stanford.edu 415-725-3723 (msg) From randyh@Synopsys.COM Wed Aug 31 12:57:25 1994 Return-Path: Received: from chronos.synopsys.com by vhdl.vhdl.org (4.1/SMI-4.1/BARRNet) id AA10669; Wed, 31 Aug 94 12:57:25 PDT Received: from gaea.synopsys.com by chronos.synopsys.com with SMTP id AA28511 (5.65c/IDA-1.4.4 for ); Wed, 31 Aug 1994 12:53:56 -0700 Received: from clotho.synopsys.com by gaea.synopsys.com with SMTP id AA18904 (5.65c/IDA-1.4.4 for ); Wed, 31 Aug 1994 12:53:54 -0700 Received: from tonga.synopsys.com (tonga.synopsys.com [146.225.82.16]) by clotho.synopsys.com (8.6.9/8.6.9) with SMTP id MAA22202 for ; Wed, 31 Aug 1994 12:53:53 -0700 Date: Wed, 31 Aug 1994 12:53:53 -0700 Message-Id: <199408311953.MAA22202@clotho.synopsys.com> X-Sender: randyh@engr.synopsys.com Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii" To: ibis@vhdl.org From: randyh@Synopsys.COM (Randolph E. "Randy" Harr) Subject: Blushing ... X-Mailer: Well, I am really blushing with all the "public" accolades. My initial purpose of the message to the reflector was just to explain why/who Bill den Beste was for you all. Thank you everyone for your kind words. The earth will really need to move when someone important like Will, Kelly, Jon, Arpad, ... moves on! BTW -- I will be staying on the reflector for now and chirping up every now and then as before. Randolph E. (Randy) Harr Till 31 August: On 1 Sep: --------------------------------------- ------------------------------------ Senior Scientist and Program Manager Senior Research Associate Dept of EE, CIS Logic Modeling Group, Synopsys Inc. Stanford University randyh@synopsys.com, (415)694-1835(o) rharr@mojave.stanford.edu 415-725-3723 (msg) From Will_Hobbs@ccm2.jf.intel.com Wed Aug 31 13:46:41 1994 Return-Path: Received: from ormail.intel.com by vhdl.vhdl.org (4.1/SMI-4.1/BARRNet) id AA11002; Wed, 31 Aug 94 13:46:41 PDT Received: from relay.jf.intel.com by ormail.intel.com with smtp (Smail3.1.28.1 #12) id m0qfwTw-000MONC; Wed, 31 Aug 94 13:42 PDT Received: from ccm.jf.intel.com by relay.jf.intel.com (Smail3.1.28.1 #2) id m0qfwTr-000twcC; Wed, 31 Aug 94 13:42 PDT Received: by ccm.jf.intel.com (ccmgate 3.0) Wed, 31 Aug 94 13:42:02 PST Date: Wed, 31 Aug 94 13:42:02 PST From: Will Hobbs Message-Id: <940831134202_4@ccm.jf.intel.com> To: ibis@vhdl.org, paulf@eos.ncsu.edu Subject: Re[2]: DAC Session Text item: Paul, I noticed you only copied me on your reply. Since it is of general interest, I've posted it to the reflector. Will I don't think we should think of it probabilistically like this. IF we arrange a session and IF the papers are of a high quality then you are not likely to be wasting your time. The 3 in 4 rejection includes all the `another dull paper on an increment in DFT only of interest to other DFT academics' rejects. We do not need to submit 12 papers. How can you tell if a paper is of a `high quality'. Would you want to take valuable time from the floor-show to go to it? ... as good a criteria as any. I would be happy to help judge candidate outlines though I do not claim any particularly great insights on acceptability. Regards, Paul > > > Text item: > > Paul, > > As Jon Powell stated, there were several concerns: > > You said that typically 3 of 4 papers are rejected. If, as we surmised, we > needed at least 3 accepted papers to have a session, does that mean the forum > members need to generate 12 papers in order for anyone to get to present? > That's a fairly big disincentive. > > There was a general feeling that a DAC session would be worthwhile, but with > products to deliver, many of us don't want to spend valuable time in the next > month writing a paper if there is only a small likelihood of it going anywhere. > How many papers does it take to reach critical mass, or is that an irrelevant > question? > > Will > 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***. Date: Wed, 31 Aug 94 16:15:34 EDT In-Reply-To: Your message of Wed, 31 Aug 94 08:39:58 -0800. <940831083958_5@ccm.jf.intel.com> Subject: Re: DAC Session To: Will Hobbs Message-Id: <9408312015.AA22401@c11059-364dan.ece.ncsu.edu> From: paulf@eos.ncsu.edu Received: by c11059-364dan.ece.ncsu.edu (5.65/Eos/C-U-09Sep93) id AA22401; Wed, 31 Aug 1994 16:15:35 -0400 Received: from c11059-364dan.ece.ncsu.edu by hermes.intel.com (5.65/10.0i); Wed, Received: from hermes by ichips.intel.com (5.64+/10.0i); Wed, 31 Aug 94 13:11:09 Received: from ichips.intel.com by relay.jf.intel.com with smtp (Smail3.1.28.1 #2) id m0qfw4f-000twfC; Wed, 31 Aug 94 13:16 PDT From keutzer@Synopsys.COM Wed Aug 31 20:36:15 1994 Return-Path: Received: from chronos.synopsys.com by vhdl.vhdl.org (4.1/SMI-4.1/BARRNet) id AA14376; Wed, 31 Aug 94 20:36:15 PDT Received: from gaea.synopsys.com by chronos.synopsys.com with SMTP id AA08018 (5.65c/IDA-1.4.4 for ); Wed, 31 Aug 1994 20:32:45 -0700 Received: from scott.synopsys.com by gaea.synopsys.com with SMTP id AA14389 (5.65c/IDA-1.4.4 for ); Wed, 31 Aug 1994 20:32:42 -0700 Received: by scott.synopsys.com (4.1/SNPS-Sub02) id AA18205; Wed, 31 Aug 94 20:32:41 PDT Date: Wed, 31 Aug 94 20:32:41 PDT From: keutzer@Synopsys.COM (Kurt Keutzer) Message-Id: <9409010332.AA18205@scott.synopsys.com> To: keutzer@Synopsys.COM, randyh@Synopsys.COM, raul@Synopsys.COM, rudell@Synopsys.COM Subject: Re: DAC Session Cc: ibis@vhdl.org DAC doesn't like unreviewed special sessions. I don't see alot of hope for this. ICCD is a better shot. Panels previewed by a tutorial seem to get more encouragement. I'm not dictating the situation I'm just commenting on what I know to be the case. KUrt