From randyh@vhdl.org Sat Oct 1 12:21:03 1994 Return-Path: Received: from by vhdl.vhdl.org (4.1/SMI-4.1/BARRNet) id AB18719; Sat, 1 Oct 94 12:21:03 PDT Date: Sat, 1 Oct 94 12:21:03 PDT Message-Id: <9410011921.AB18719@vhdl.vhdl.org> X-Sender: randyh@vhdl.vhdl.org Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii" To: huq@rockie.nsc.com (Syed Huq), ibis@vhdl.org From: randyh@vhdl.org (Randolph E. "Randy" Harr) Subject: Re: v2.0 RS-232 model ready X-Mailer: Congratulations on adding to the IC vendor list supporting IBIS models. It is an important step. At 01:20 PM 9/29/94 PDT, Syed Huq wrote: >Hi, >I have a v2.0 model available for verification by Simulation >vendors. I have passed this to the some companies on a request >basis only. Once I get some feedback, it will be offically >released to the IBIS forum. > >Sometime in mid OCT, I will also pass around 2 more models that >use the differential features. > >Regards, >Syed Huq >National Semiconductor. > > > Randolph E. (Randy) Harr, Senior Research Associate Dept of EE, CSL, Stanford University, Stanford, CA 94305-4070 randy.harr@vhdl.org, rharr@mojave.stanford.edu, 415-725-3639 (o), 415-725-6949 (f) From Arpad_Muranyi@ccm.fm.intel.com Mon Oct 3 10:26:56 1994 Return-Path: Received: from ormail.intel.com by vhdl.vhdl.org (4.1/SMI-4.1/BARRNet) id AA11205; Mon, 3 Oct 94 10:26:56 PDT Received: from relay.jf.intel.com by ormail.intel.com with smtp (Smail3.1.28.1 #12) id m0qrjbu-000MOBC; Mon, 3 Oct 94 02:23 PDT Received: from ccm.hf.intel.com by relay.jf.intel.com (Smail3.1.28.1 #2) id m0qrr6M-000tweC; Mon, 3 Oct 94 10:23 PDT Received: by ccm.hf.intel.com (ccmgate 3.0) Mon, 3 Oct 94 10:23:02 PST Date: Mon, 3 Oct 94 10:23:02 PST From: Arpad Muranyi Message-Id: <941003102302_1@ccm.hf.intel.com> To: ibis@vhdl.org Subject: Monotonocity check Text item: Text_1 Hello everyone, Paul needs clarification regarding the monotonocity checking algorithm in order to be able to do it correctly in the parser. He discovered that the wording of the monotonocity requirements section actually describes curves that are monotonic on BOTH axes, while the summary statement on the bottom of that section says "non-monotonic in ONE axis". I believe our intension was to require curves to be monotonic in one axis only, so I think we need to revisit these eight poits below. Here is the section from the IBIS2.0 spec: $| Monotonicity Requirements: $| To be monotonic, the V/I table data must meet any one of the $| following 8 criteria: $| 1- The CURRENT axis either increases or remains constant as $| the voltage axis is increased. $| 2- The CURRENT axis either increases or remains constant as $| the voltage axis is decreased. $| 3- The CURRENT axis either decreases or remains constant as $| the voltage axis is increased. $| 4- The CURRENT axis either decreases or remains constant as $| the voltage axis is decreased. $| $| 5- The VOLTAGE axis either increases or remains constant as $| the current axis is increased. $| 6- The VOLTAGE axis either increases or remains constant as $| the current axis is decreased. $| 7- The VOLTAGE axis either decreases or remains constant as $| the current axis is increased. $| 8- The VOLTAGE axis either decreases or remains constant as $| the current axis is decreased. $| $| Note that the above conditions allow the data to be $| non-monotonic in one axis. Arpad Muranyi Intel Corporation From bob@icx.com Mon Oct 3 16:52:14 1994 Return-Path: Received: from uu4.psi.com by vhdl.vhdl.org (4.1/SMI-4.1/BARRNet) id AA15171; Mon, 3 Oct 94 16:52:14 PDT Received: by uu4.psi.com (5.65b/4.0.071791-PSI/PSINet) via UUCP; id AA19411 for ; Mon, 3 Oct 94 19:31:13 -0400 Date: Mon, 3 Oct 94 16:11:29 PDT From: bob@icx.com ( Bob Ross) Received: by icx.com (4.1/3.2.083191-Interconnectix Inc.) id AA18463; Mon, 3 Oct 94 16:11:29 PDT Message-Id: <9410032311.AA18463@icx.com> To: 73053.721@compuserve.com, arpad_muranyi@ccm.fm.intel.com, ibis@vhdl.org Subject: Re: monotonic data Paul, I was on vacation until today (Oct 3), so I am now just catching up. The full description concerning monotonocity behavior and appropriate IBIS_CHK tests is discussed in BIRD8.2 and BIRD11.2. The texts of both are included below. In doing the inclusion of BIRD8.2, we left out some text which emphasizes that "MONOTONIC DATA IS NOT REQUIRED". The Specification gives definitions of monontonicity. BIRD8.2 states that if non-monotonic data is detected, then then only one message per table is reported. This should be a WARNING "NOTE", since the file may still be IBIS compliant. Some specific answers are included in your questions, but refer to BIRD8.2 for the full interpretation and intent. BIRD11.2 gives a separate end-point test. I cannot locate any mail from you concerning time-correlated data, so please resend that email. Bob Ross, Interconnectix, Inc. > Bob, > In reading the spec about monotonic data for the V/I curves I believe > the 8 criteria basically means that once the data is moving in one direction > (increasing or decreasing) then it can only continue in that direction or > remain constant. ^^^^^^^^^^^^^^^ ||||||||||||||| IN EACH OF THE 8 CASES, THERE IS A STATEMENT THAT ONE OF THE AXIS (VOLTAGE OR CURRENT) IS EITHER INCREASING OR DECREASING. THEREFORE, ONE TEST SHOULD BE FOR ONE OF THE AXIS TO CONTINUE IN AN INCREASING OR DECREASING DIRECTION ONLY. (EQUAL VALUED ENTRIES ARE A VIOLATION OF THIS CONDITION). THIS IS A RESTRICTION THAT ONE OF THE AXIS MUST HAVE SORTED DATA (AS OPPOSED TO BEING RANDOMLY POSITIONED) AND THAT THERE CANNOT BE SAME-VALUED ENTRIES IN THAT AXIS. THUS, THE IDEAL STEP FUNCTION WITH MULTIPLE VOLTAGE AND CURRENT VALUES (EQUAL VALUES IN BOTH AXIS) SHOULD GENERATE A WARNING. TWO ACCEPTABLE ALTERNATIVES ARE ALSO GIVEN. (THIS IS MY INTERPRETATION BASED ON A RIGID READING OF THE SPECIFIED CONDITIONS, AND IS ALSO A PRACTICAL RESTRICTION BASED ON GUARENTEEING SINGLE-VALUED FUNCTIONS.) ^ NO YES OR YES | ___ V I V I V I I | 0 0 0 0 0 0 __| 1 O 1 0 1 0.01 1 2 1.01 2 1 2 V -> 2 2 2 2 2 2.01 > For example, if the current started off increasing, it should never decrease. > Or, if the voltage started off decreasing, it should never increase. THE MORE RESTRICTIVE TEST WOULD BE THAT ONE AXIS MUST CONTINUE TO INCREASE OR CONTINUE TO DECREASE TO AVOID MULIPLE VALUED FUNCTIONS. > That may seem too general, but that's how I'm taking it. What confuses me > is that directly after the 8 criteria there is the statement: > "Note that the above conditions allow the data to be non-monotonic in > one axis." > What does that mean? Can the voltage go up and down within the same curve? ONCE AN AXIS IS IDENTIFIED AS INCREASING OR DECREASING, THEN THE SECOND AXIS CAN BE EXAMINED. THE SECOND AXIS DOES NOT HAVE TO BE MONOTONIC. HOWEVER, A TEST OF THE SECOND AXIS FOR EQUAL-OR-SAME_DIRECTION_CHANGE IS GIVEN BY ONE OF THE EIGHT CONDITIONS WHICH DEFINE "MONOTONIC" BEHAVIOR. IF SUCH BEHAVIOR IS NOT DETECTED THEN BIRD8.2 SPECIFIES A WARNING "NOTE". > Can the current go up and down within the same curve? YES > Do the 8 criteria apply > to an entire table, or just to portions of it? ENTIRE TABLE - ALL ENTRIES OF ANY AXIS, AND ALSO TO THE MIN AND MAX CURRENT TABLE ENTRIES, IF DEFINED. > I was talking with Donald Telian and > he was confused with this also, although he thought he understood the issue. A SEPARATE TEST IS DESCRIBED IN BIRD11.2 FOR POLARITY CHECKING AND IS BASED ON JUST THE VOTAGE MIN AND MAX VALUES OF THE TYPICAL CURRENT CURVE ONLY. > Any assistance would be greatly appreciated. Did you get my mail about the > time correlated data? > Paul Munsey (73053.721@compuserve.com) BIRD 8.2 FOLLOWS: ******************************************************************************* ******************************************************************************* Buffer Issue Resolution Document (BIRD) BIRD ID#: 8.2 ISSUE TITLE: Specification of V/I data monotonicity REQUESTOR: Kellee Crisafulli, HyperLynx Inc. DATE SUBMITTED: January 29, 1994 DATE REVISED: 5-9-94 DATE ACCEPTED BY IBIS OPEN FORUM: {pending} ******************************************************************************* ******************************************************************************* STATEMENT OF THE ISSUE: Statements have been made at various meetings specific to V/I data and monotonicity. This information has not been added to the specification. It is therefore the intent of this BIRD to add a monotonicity statement to the version 2.0 IBIS specification. ******************************************************************************* STATEMENT OF THE RESOLVED SPECIFICATIONS: (The proposed changes start on the 20th line after 'Keywords:'. Note: An '*' is used to denote the changed lines) |============================================================================== | Keywords: [Pulldown], [Pullup], [GND_clamp], [POWER_clamp] | Required: Yes, if they exist in the device | Description: The data points under these keywords define the V/I curves -of | the pulldown and pullup structures of an output buffer -and the | V/I curves of the clamping diodes connected to the GND -and the | POWER pins, respectively. | Usage Rules: In each of these sections the first column contains the | voltage value, and the three remaining columns hold the | typical, minimum, and maximum current values. The four | entries, Voltage, I(typ), I(min), and I(max) 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 under these keywords, however | data is only required in the typical column. If minimum | and/or maximum current values are not available, the reserved | word "NA" must be used. "NA" can be used for currents in the | typical column, but numeric values MUST be specified for the | first and last voltage points on any V/I curve. Each V/I | curve must have at least 2, but not more than 100, voltage | points. | * The V/I table DATA SHOULD BE MONOTONIC to insure that most * simulators provide stable simulations. Monotonic data is * needed to insure that all data is single valued. MONOTONIC * DATA IS NOT REQUIRED to provide a valid IBIS model. * It is recognized that automated measurement equipment may * be used to acquire this data and as such may include "noise" * which causes the data to be non-monotonic. It is also recognized * that some device may be non-monotonic in certain regions. * Therefore the IBIS specification allows non-monotonic data. * Simulation tools should filter out non-monotonic data if * such data causes instabilities in the simulation results. * To be monotonic the V/I table data must meet any one of the * following 8 criteria: * 1- The CURRENT axis either increases or remains constant as * the voltage axis is increased. * 2- The CURRENT axis either increases or remains constant as * the voltage axis is decreased. * 3- The CURRENT axis either decreases or remains constant as * the voltage axis is increased. * 4- The CURRENT axis either decreases or remains constant as * the voltage axis is decreased. * * 5- The VOLTAGE axis either increases or remains constant as * the current axis is increased. * 6- The VOLTAGE axis either increases or remains constant as * the current axis is decreased. * 7- The VOLTAGE axis either decreases or remains constant as * the current axis is increased. * 8- The VOLTAGE axis either decreases or remains constant as * the current axis is decreased. * * The IBIS_CHK program will test for non-monotonic data and * provide a maximum of one note per V/I table if non-montonic * data is found. * "NOTE: Line xxx of V/I table yyy for model zzz is * non-monotonic! Most simulators will filter this data * to remove the non-monotonic data." * Where xxx is the line number in the IBIS file. * Where yyy is Pullup, Pulldown, GND_clamp or POWER_clamp. * Where zzz is the name of the model. * * It is also recognized that the some data may be monotonic if * currents from both the output stage and the clamp diode are * added together as most simulators do. To limit the complexity * of the version 2.0 IBIS_CHK program, it will consider only one * V/I table at a time monotonicity testing. * | Other Notes: It should be noted that the V/I curve of the [Pullup] and the | [POWER_clamp] structures are 'Vcc relative', meaning that the | voltage values are referenced to the Vcc pin. The voltages in | the data tables are derived from the equation: | Vtable = Vcc - Voutput | Therefore, for a 5V component, -5 V in the table actually | means 5 V above Vcc, which is +10 V with respect to ground; | and 10 V means 10 V below Vcc, which is -5 V with respect to | ground. Vcc-relative data is necessary to model a pullup | structure properly, since the output current of a pullup | structure depends on the voltage between the output and Vcc | pins and not the voltage between the output and ground pins. | Note that the [GND_clamp] V/I curve can include quiescent | input currents, or the currents of a 3-stated output if so | desired. |------------------------------------------------------------------------------ ******************************************************************************* ANALYSIS PATH/DATA THAT LED TO SPECIFICATION: I reviewed the previous discussions the results of the 1993 summit. Considerable email has passed on this discussion. ******************************************************************************* ANY OTHER BACKGROUND INFORMATION: The IBIS_CHK program must also be modified to test for this condition. ------------------------------------------------------------------------------ >From meeting Nov 5, 1993 1) Non-monotonic buffer behavior: Arpad asked, "Do we require monotonic behavior in curves?" If this is a requirement, the parser must check for monotonicity. Jon Powell said that customers want to model non-monotonic parts. Non-monotonic behavior can result from slow feedback designed to prevent parts from melting; thus is is more of a DC phenomenon than an AC phenomenon. Does this pose a convergence problem for some simulators? Is a DC representation of the curve acceptable for some devices? Due to DC current limiting, DC measurements may imply non-monotonic behavior that would never actually occur under real switching conditions. How do we measure in an AC manner instead of DC manner? Behavior that is nonmonotonic due to feedback goes into the controlled slew rate discussion, modeling the dynamic characteristics of device. For IBIS to be useful, it must deal with negative resistance regions. 2) Monotonic data entry: We felt that in IBIS tables, voltage values should be monotonically rising or falling, but that current values may change. The parser should check whether the data is good, but it shouldn't restrict the type of data. A BIRD against the parser should be written at some point to add checks for this in rev 2.0. No specific AR owner was identified. ------------------------------------------------------------------------------ 1993 Summit minutes: There are several defined buffer types (input, output, I/O, tri-state, open drain), which drives what information you collect. Collection of data from measurement is a decomposition problem, of trying to sort out the effects of clamps from buffers etc. The companies with whom Bob has worked (Zeelan and Interconnectix) do this decomposition with software. One problem is selecting measurement regions with abnormal behavior, such as non-monotonic behavior caused by device switching or "jumps" in the ESD protection during sweeps. Their software does some filtering of data to eliminate false abnormal behavior. They can also filter for monotonic behavior. Monotonicity, General Discussion -------------------------------- We clarified that one axis of data representation should be monotonic, such as the voltage axis on the V/I curve, but that we could not require that the other axis be monotonic, since we were modeling real components whose nature may not be monotonic. ------------------------------------------------------------------------------- ******************************************************************************** BIRD11.2 FOLLOWS: >From: Kellee Crisafulli To: IBIS world at large and growing Re: Bird 11.2 modified per inputs from Bob Ross and last meeting Date: April 21, 1994 I have made the changes per inputs from Bob Ross and per feedback from the last IBIS meeting as retold to me by Bob. See the end of this file for change discussion. Change 2: 'IF-ELSE' conditions were modified to add equal Change 3: Added equal condition to verification requirment Change 4: Removed requirment to stop IBIS_CHK on first error. Sorry I missed the last meeting, UNCLE SAM was calling. I was one of those procrasting people still working on my personal TAXES at the last minute. ******************************************************************************* ******************************************************************************* Buffer Issue Resolution Document (BIRD) BIRD ID#: 11.2 ISSUE TITLE: Improving common error detection in IBIS_CHK program. REQUESTOR: Kellee Crisafulli, HyperLynx Inc. DATE SUBMITTED: 03-28-94 DATE REVISED: 04-21-94 DATE ACCEPTED BY IBIS OPEN FORUM: TBD ******************************************************************************* ******************************************************************************* STATEMENT OF THE ISSUE: Several common problems with IBIS models are not detected with the present version of IBIS_CHK. Two main problems include: 1) Incorrect 'I'(current) signs in the V/I tables. 2) Pullup and POWER_clamp V/I tables are not VCC relative. This BIRD is directed at problem 1 only. A 2nd separate BIRD will be generated to address problem 2. ******************************************************************************* STATEMENT OF THE RESOLVED SPECIFICATIONS: The following changes apply to version 1.1 and forward versions of the IBIS_CHK program and including testing of some parameters for BIRD 7.2 for ECL model types *************************************************************************** Change 1- Add verbage on current direction. *************************************************************************** Keywords: [Pullup], [Pulldown], [GND_clamp], [POWER_clamp] Required: Yes, if they exist in the device Description: The data points under these keywords define the V/I curves of the pulldown and pullup structures of an output buffer and the V/I curves of the clamping diodes connected to the GND and the POWER pins, respectively. Currents are considered positive when their direction is into the component. *************************************************************************** Change 2- Add detection to IBIS_CHK program for V/I table 'I' sign errors. *************************************************************************** For each of the following V/I tables: Pullup, Pulldown, POWER_clamp, GND_clamp 1) Find the minimum and maximum voltage points (Vmin, Vmax) in the table. 2) IF:The current in the TYPICAL column corresponding to Vmax is less than the current in the TYPICAL column corresponding to Vmin than the table is assumed to have decreasing current. ELSE IF:The current in the TYPICAL column corresponding to Vmax is greater than the current in the TYPICAL column corresponding to Vmin than the table is assumed to have increasing current. ELSE: The table is assumed to have equal current." Note: This works for all cases of discontinuities unless the magnitude of discontinuity is such that this model is in all probability competely unrealistic. Examples: *** example with non-monotonic data at the end point V: I: 0.00 0.0 4.90 50.0ma 4.91 49.9ma 4.93 56.7ma 5.00 3.0ma -> V/I table has increasing current (3.0 > 0) Vmax = 5.0, I =3.0mA Vmin = 0.0, I =0.0 *** example with negative to positve voltages with negative first V: I: -5.00 -0.1ma 0.00 0.0 5.00 100.0ma -> V/I table has increasing current (100 > -0.1) Vmax = 5.0, I=100mA Vmin = -5.0, I=-0.1mA *** example with table data entered postive voltages first V: I: 5.00 10.1ma 0.00 0.0 -5.00 -10.1ma -> V/I table has increasing current (10.1 > -10.1) Vmax = 5.0, I=10.1mA Vmin = -5.0, I=-10.1mA *** example with only two entrys V: I: 0.00 0.0 -5.00 10.1ma -> V/I table has decreasing current (0 < 10.1) Vmax = 0.0, I=0 Vmin = -5.0, I=10.1mA *** ECL example [Pullup] Voltage I(typ) I(min) I(max) 0.0 0 0 0 0.7 -0.2m -0.2m -0.2m 0.73 -0.4m -0.4m -0.4m 0.75 -0.8m -0.8m -0.8m 0.76 -1.2m -1.2m -1.2m 0.77 -1.6m -1.6m -1.6m 0.8 -4.4m -4.4m -4.4m 0.82 -7.6m -7.6m -7.6m 0.85 -14.2m -14.2m -14.2m 0.9 -30.0m -30.0m -30.0m 1.0 -58.0m -50.0m -68.0m -> V/I table has decreasing current ( -58 < 0) Vmax = 1.0, Ityp=-58mA Vmin = 0, Ityp=0 [Pulldown] Voltage I(typ) I(min) I(max) 0.0 0 0 0 1.6 -0.2m -0.2m -0.2m 1.62 -0.4m -0.4m -0.4m 1.64 -0.6m -0.6m -0.6m 1.65 -0.8m -0.8m -0.8m 1.66 -1.2m -1.2m -1.2m 1.67 -1.6m -1.6m -1.6m 1.68 -2.4m -2.4m -2.4m 1.69 -3.2m -3.2m -3.2m 1.70 -4.4m -4.4m -4.4m 1.72 -7.4m -7.4m -7.4m 1.75 -14.2m -14.2m -14.2m 1.8 -30.5m -30.5m -30.5m 1.9 -65.0m -60.0m -75.0m -> V/I table has decreasing current ( -65 < 0) Vmax = 1.9, Ityp=-65mA Vmin = 0.0, Ityp= 0 *** An abreviated INTEL model for a CMOS output |**************************************************************************** [Pulldown] | Voltage I(typ) I(min) I(max) -5.00V -38.70mA -29.47mA -51.22mA -1.00V -24.88mA -19.18mA -32.90mA -0.50V -14.35mA -11.06mA -19.05mA 0.00V -11.84pA -554.66pA -11.03pA 100.00mV 3.20mA 2.47mA 4.27mA 200.00mV 6.24mA 4.80mA 8.30mA 4.90V 38.68mA 29.45mA 51.18mA 5.00V 38.70mA 29.47mA 51.22mA 10.00V 39.96mA 30.37mA 53.06mA -> V/I table increasing [GND_clamp] | Voltage I(typ) I(min) I(max) -5.00V -680.00mA NA NA -1.10V -75.50mA NA NA -600.00mV -950.00uA NA NA -500.00mV -78.00uA NA NA -200.00mV 0.00pA NA NA -100.00mV 0.00pA NA NA 0.00V 0.00pA NA NA 5.00V 0.00pA NA NA -> V/I table increasing (0 > -680) [Pullup] | Voltage I(typ) I(min) I(max) -5.00V 38.14mA 27.33mA 54.76mA -4.50V 37.49mA 26.87mA 53.79mA -1.00V 17.13mA 12.81mA 23.55mA -0.50V 9.26mA 6.96mA 12.66mA 0.00V 13.57pA 613.51pA 11.04pA 100.00mV -1.96mA -1.48mA -2.67mA 200.00mV -3.87mA -2.92mA -5.27mA 500.00mV -9.26mA -6.96mA -12.66mA 1.80V -26.79mA -19.79mA -37.25mA 1.90V -27.74mA -20.46mA -38.64mA 4.60V -37.62mA -26.97mA -54.00mA 4.70V -37.76mA -27.06mA -54.20mA 5.00V -38.14mA -27.33mA -54.76mA 10.00V -44.52mA -33.72mA -61.15mA -> V/I table decreasing [POWER_clamp] | Voltage I(typ) I(min) I(max) -5.00V 1.05A NA NA -1.10V 79.00mA NA NA -1.00V 54.00mA NA NA -900.00mV 29.00mA NA NA -800.00mV 10.40mA NA NA -200.00mV 0.00uA NA NA -100.00mV 0.00uA NA NA 0.00V 0.00pA NA NA -> V/I table decreasing 3) IF the model is any of the following types:(Input_ECL, Output_ECL, I/O_ECL) { Verify that: - Pullup V/I table has equal or decreasing current - POWER_clamp V/I table has equal or decreasing current - Pulldown V/I table has equal or decreasing current - GND_clamp V/I table has equal or increasing current } ELSE { Verify that: - Pullup V/I table has equal or decreasing current - POWER_clamp V/I table has equal or decreasing current - Pulldown V/I table has equal or increasing current - GND_clamp V/I table has equal or increasing current } Note: This specifically allows constant current generators and 0 current tables. 0 current tables may be used to indicate table is unused. 4) If any table verification fails report the following error message: 'Error found in xxx V/I table at line number nnn!'. Where xxx is one of the following Pullup, Pulldown, POWER_clamp, GND_clamp. Where nnn is the line number. *************************************************************************** Change 3- Add a header comment statement at the TOP of the IBIS_CHK program to insure that new changes to the IBIS_CHK program donot break tests that worked in old MAJOR versions. This approach makes the program larger however it insures the parser always works the same on older versions of IBIS. This apporach uses more memory, but has the reward of low maintaining costs. The IBIS_CHK program is very small and would not be effected by this until many revisions have occured. *************************************************************************** NOTICE TO ANY PERSON MODIFING THIS PROGRAM! ------------------------------------------- This program SHALL NOT BE MODIFIED unless there is an associated IBIS BIRD. Said BIRD shall be agreed upon by IBIS committee vote. Only the currently elected IBIS_CHK 'czar and programmer' is allowed to modify the source code. The present CZAR is Jon Powell (April 1994). The IBIS committee may also hire programmers from time to time to make major changes to the source code. Note: Source licensees are free to modify their own copies of this source code in any way they choose. Source licensees shall not redistribute the source code modified or otherwise. Source licensing is available from the IBIS open forum. The IBIS open forum is non-profit. The code for each MAJOR version of the IBIS_CHK program SHALL NOT BE MODIFIED when adding code for the next version of the IBIS specification. Instead completely new code for all functions and features shall be created. This may require duplication of numerous functions. Each function shall be preceded by VXX_ where XX is the MAJOR version of the IBIS specification which is being parsed and tested. A MAJOR version would for example be 1.x going to 2.x. A MINOR version would for example be 1.1 to 1.2. Functions using the above syntax would look as follows: V01_GetValue MINOR revisions DO NOT required new code. Startup code shall be provided at the top of the program which reads the version number from the IBIS file and runs the portion of the program corresponding to that MAJOR version. Code which is used only by the program startup function is not duplicated. ******************************************************************************* ANALYSIS PATH/DATA THAT LED TO SPECIFICATION: Change 1) Suggested from inputs of several people in Email and at the at previous IBIS meetings. Change 2) Defective IBIS models are slipping through the IBIS_CHK program. A method for determining sign errors in V/I table was determined based on inputs from several people including: Kellee Crisafulli, HyperLynx Jon Powell, Quad Design Arpad, Intel Bob Ward, TI Bob Ross, Interconnectix Maah Sango, Contec I reviewed all the comments that have been submitted and I believe this method will work with all conditions mentioned so far. Change 3) I am proposing a method of insuring that future IBIS_CHK modifications donot effect the parsing of older IBIS files. This only applies to MAJOR revisions in the specification, like 2.0 comming up. This would not apply to this update, it would however be added to the program header information now and would apply to all future MAJOR updates to the IBIS specification. ******************************************************************************* ANY OTHER BACKGROUND INFORMATION: Comments about EMAIL leading up to this BIRD -------------------------------------------- >From: Jon Powel, qdt Cases that will not work for proposed algorithm V: I: 0.0 0.0 3.5 50.0 3.51 49.9 3.52 49.8 3.53 49.7 5.0 100.0 any OC any OD If current is not negative at GND for the pullup then it cannot pullup? (except for ECL OC etc?). Action: problems fixed in BIRD 11.0 ****************** >From: Arpad, Intel What happens if there are equal number of increases and decreases in a curve? Most of the curves I am generating lately do that and I do not think I am doing it wrong. Action: problems fixed in BIRD 11.0 ******************** Bob Ward, TI I think the proposed method of current sign determination might run into trouble in at least two cases. One is when there are exactly the same number of rising and falling segments. The other is the same problem one runs into testing for monotonicity of the independent variable. That problem is that very small oscillations occur on the "flat" part of a numerically generated curve, not so much because they are real, but because of the nature of small numbers, finite precision, and floating point round off. Action: Problems fixed in BIRD 11.0 ****************************** Bob Ross, Interconnectix, Inc. If this proposal is adopted, it would apply to just IBIS Version1.1. The polarity rules do not comply with proposed IBIS extensions BIRDS 3 and 4 for ECL type devices. For ECL type devices, the polarities of both the Pullup and Pulldown tables will go in the same (decreasing) direction because BOTH tables are tabulated referenced to Vcc using Vtable = Vcc - Vout. I am sure this will become another area of confusion, justifying a test. Action: Problem fixed BIRD 11.0 ************************** Maah Sango, Contec Microelectronics USA Inc 2. I agree with Bob Ross that the proposed scheme for enforcing data integrity will not work for ECL, nor for a few other device types. (See item 3 of the proposal). Either the "pullup" or the "pulldown" data for the ECL and other device types will violate these requirements. Action: Problem fixed Bird 11.0 3. The proposed scheme, item 3, will not always work even for CMOS unless we use only the magnitudes of the currents. Existing data for ageing (old) devices is sometimes presented with positive currents and sometimes with negative currents for CMOS pullup devices. Action: Problem fixed Bird 11.0 4. I am not sure that checking only the two end points will always guarantee the conclusions we are assuming here. Current(I) data in between these two points may increase or decrease and still be perfectly valid, particularly if we think of device types other than CMOS. Action: Numerous examples cited, none found that present a problem ******************************* Arpad, Intel If we JUST want a polarity checker for the MOST COMMON error, I have another most common error to check for: VCC-relative! That needed more explaining than the polarity of the current in my experience, and I have seen more people being confused about that. Should that also be checked for then? Action: Another Bird needs to be generated separate from Bird 11 ******************************************************************************* Changes from the April-1-94 IBIS meeting BIRD 11, IBIS_CHK Changes Kellee Crisafulli proposes three changes in this BIRD, each related to the sign of VI table data, which has proven to be a common pitfall among new modelers. First, the BIRD proposes adding a comment to the IBIS specification discussing the sign of VI table data; second, add checking to ibis_chk for the correct sign, using the algorithm tuned through reflector feedback; and third, add a note to the ibis_chk source saying a BIRD is required to change the source. Proposed changes 1 and 3 appear OK to group, with the additional comment that source licensees are free to modify their own source, but not to post the result. Only the ibis_chk czar (Jon Powell) can post modified versions of ibis_chk, and that requires a ratified BIRD to initiate. AR:Kellee, change the proposed ibis_chk notice to indicate that it is OK to change your own source code, but not the global one without a supporting BIRD. Action: Done Regarding change 2, there is controversy about the sign of the ECL example. Kellee pulled the example out of the IBIS V1.1 spec, which was a CMOS example, and indicated that if this was an ECL example then there would be a sign error because for ECL pulldown, VI is Vcc-V per BIRD 4. Kellee feels that right thing to do is to change the sign and use ECL type data and present a correct ECL table, but doesn't have ECL data. Kumar has ECL data which he offered to supply for inclusion in the BIRD. AR:Kumar, post ECL model to reflector, Kellee, use that data in the BIRD. Action: I have incorporated the model. AR Kellee, Two people noted that the directions of the current tests for the ECL were wrong. Kellee thought they were correct during the phone conversation. Action: I was wrong, and have changed them to correct the problem. ******************************************************************************* Changes April 15 meeting and inputs from Bob Ross, Interconnectix Inc. Will tables composed of only 0 mA entries or of only constant current entries be flagged as an error in Version 2.0? They are acceptable in Version 1.1, and could be useful to get around some Model_type omissions and do some (beyond IBIS) constant current source modeling or biasing of tables modeling. Input at the meeting 4-15-94 indicated that 0mA and constant current should be allowed. Change 2, section 4) states: If any table moves in the wrong direction report the following error message: 'Error found in xxx V/I table at line number nnn!'. Where xxx is one of the following: Pullup, Pulldown, POWER_clamp, GND_clamp. Where nnn is the line number. Note: It is acceptable to stop the parser after the first line found with this error." I could technically be very happy with the wording as is, and yet we may have entirely different expectations. To me "If any table MOVES in the wrong direction ..." means an error is NOT reported if there is NO table movement - e.g., NO error is reported if the tests reveal EQUAL currents. I believe you really intended "If any table verification fails ...". I would prefer that the IBIS_CHK parser not stop, but continue to check the file for all errors (including other occurances of this error). So I would delete the "Note" entirely. AR Kellee, Modify the test to allow constant current and 0mA as valid. Action: I have made changes in the V/I table tests to allow 0mA and constant current. AR Kellee, Clarify wording and remove requirment to stop IBIS_CHK on first error. Action: Modified wording to say "If any table verification fails..." Deleted the Note requiring the parser to stop after the first error line. ************************************************************************************* From bob@icx.com Mon Oct 3 17:37:59 1994 Return-Path: Received: from uu4.psi.com by vhdl.vhdl.org (4.1/SMI-4.1/BARRNet) id AA15869; Mon, 3 Oct 94 17:37:59 PDT Received: by uu4.psi.com (5.65b/4.0.071791-PSI/PSINet) via UUCP; id AA28515 for ; Mon, 3 Oct 94 20:22:57 -0400 Date: Mon, 3 Oct 94 17:06:06 PDT From: bob@icx.com ( Bob Ross) Received: by icx.com (4.1/3.2.083191-Interconnectix Inc.) id AA18895; Mon, 3 Oct 94 17:06:06 PDT Message-Id: <9410040006.AA18895@icx.com> To: 73053.721@compuserve.com, ibis@vhdl.org Subject: Re: IBIS Spec Paul, I found your timing question: I believe that this statement should be for developer guidance only, but NOT for IBIS_CHK. The intent is for the same stimulus reference time (or input) to be used for all rising waveforms, and similarly, the same stimulus reference time (which can differ from the rising waveform) or input be used for all falling waveforms. Thus all variations are due only to to loading changes. The simulator can assume common input reference times for possible interpolation algorithms. There is no way within IBIS to specify the input waveforms for output responses, so constraining them to a common reference time is one way of eliminating the effects of input waveform variations. Bob Ross Interconnectix, Inc. > Bob, > I had a question as to some usage rules for rising and falling waveforms. > Under [Rising Waveform] and [Falling Waveform] keywords, the 3rd paragraph > states "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 ust be entered with respect to a common reference point on the input > stimulus waveform." > I don't understand what this is trying to say. Is this something the parser can > check for, or is it just something that the developers of IBIS files need to keep > in mind? > Paul Munsey From jonp@qdt.com Tue Oct 4 08:43:29 1994 Return-Path: Received: from relay3.UU.NET by vhdl.vhdl.org (4.1/SMI-4.1/BARRNet) id AA25617; Tue, 4 Oct 94 08:43:29 PDT Received: from uucp7.UU.NET by relay3.UU.NET with SMTP id QQxkeg01108; Tue, 4 Oct 1994 11:39:39 -0400 Received: from qdt.UUCP by uucp7.UU.NET with UUCP/RMAIL ; Tue, 4 Oct 1994 11:39:43 -0400 Received: from hal.qdt.com by qdt.com (4.1/SMI-4.1) id AA00417; Tue, 4 Oct 94 08:29:41 PDT Received: from f14.qdt.com by hal.qdt.com (4.1/SMI-4.1) id AA28314; Tue, 4 Oct 94 08:28:47 PDT Date: Tue, 4 Oct 94 08:28:47 PDT From: jonp@qdt.com (Jon Powell) Message-Id: <9410041528.AA28314@hal.qdt.com> Received: by f14.qdt.com (4.1/SMI-4.1) id AA05574; Tue, 4 Oct 94 08:28:34 PDT To: ibis@vhdl.org Subject: [uunet!icx.com!bob: Re: IBIS Spec] Bob and Paul et. al. The "Timing Correlation" remark here, though indeed a function of loading, is actually to allow for the detection of rise-time-controlled component drivers. In these cases the Pull-up and pull-downs turn on and off with delay (So the pull-up would turn off before the pull-down turns on etc). There is no way to test for this in the parser. There are perhaps so complicated "suspicious data" tests you could do but I don't think I would recommend it at this point. jonp Return-Path: Date: Mon, 3 Oct 94 17:06:06 PDT From: uunet!icx.com!bob ( Bob Ross) To: uunet!compuserve.com!73053.721, uunet!vhdl.org!ibis Subject: Re: IBIS Spec Paul, I found your timing question: I believe that this statement should be for developer guidance only, but NOT for IBIS_CHK. The intent is for the same stimulus reference time (or input) to be used for all rising waveforms, and similarly, the same stimulus reference time (which can differ from the rising waveform) or input be used for all falling waveforms. Thus all variations are due only to to loading changes. The simulator can assume common input reference times for possible interpolation algorithms. There is no way within IBIS to specify the input waveforms for output responses, so constraining them to a common reference time is one way of eliminating the effects of input waveform variations. Bob Ross Interconnectix, Inc. > Bob, > I had a question as to some usage rules for rising and falling waveforms. > Under [Rising Waveform] and [Falling Waveform] keywords, the 3rd paragraph > states "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 ust be entered with respect to a common reference point on the input > stimulus waveform." > I don't understand what this is trying to say. Is this something the parser can > check for, or is it just something that the developers of IBIS files need to keep > in mind? > Paul Munsey From Will_Hobbs@ccm2.jf.intel.com Tue Oct 4 15:06:18 1994 Return-Path: Received: from ormail.intel.com by vhdl.vhdl.org (4.1/SMI-4.1/BARRNet) id AA28964; Tue, 4 Oct 94 15:06:18 PDT Received: from relay.jf.intel.com by ormail.intel.com with smtp (Smail3.1.28.1 #12) id m0qsARX-000MOCC; Tue, 4 Oct 94 07:02 PDT Received: from ccm.jf.intel.com by relay.jf.intel.com (Smail3.1.28.1 #2) id m0qsHw2-000tweC; Tue, 4 Oct 94 15:02 PDT Received: by ccm.jf.intel.com (ccmgate 3.0) Tue, 4 Oct 94 15:02:10 PST Date: Tue, 4 Oct 94 15:02:10 PST From: Will Hobbs Message-Id: <941004150210_1@ccm.jf.intel.com> To: bob@icx.com, 73053.721@compuserve.com, Arpad_Muranyi@ccm.fm.intel.com, ibis@vhdl.org Subject: Re[2]: monotonic data Text item: External Message Header Bob, Thanks for the clarification. I had already replied to Paul with a comment that was not as accurate or complete as yours, so I appreciate your follow-through. The time-correlation question related to how multiple waveform tables could be used, which requires that a point, such as 0.8 or 1.5 V, be picked by the simulator as a reference to time-correlate the waveforms. I believe that the parser does not have to do anything but create the table data structures and check for rule compliance. Will From cer@Cadence.COM Wed Oct 5 06:28:00 1994 Return-Path: Received: from mailgate.cadence.com by vhdl.vhdl.org (4.1/SMI-4.1/BARRNet) id AA07501; Wed, 5 Oct 94 06:28:00 PDT Received: (from smap@localhost) by mailgate.cadence.com (8.6.8/8.6.8) id GAA29871 for ; Wed, 5 Oct 1994 06:24:11 -0700 Received: from cadence.cadence.com(158.140.18.1) by mailgate.cadence.com via smap (V1.0mjr) id sma029840; Wed Oct 5 06:23:41 1994 Received: from oahu by cadence.Cadence.COM (5.61/3.14) id AA16610; Wed, 5 Oct 94 06:21:31 -0700 Received: by oahu (5.65+/1.5) id AA06070; Wed, 5 Oct 94 09:23:55 -0400 Date: Wed, 5 Oct 94 09:23:55 -0400 From: cer@cadence.com (Chrisopher E. Reid) Message-Id: <9410051323.AA06070@oahu> To: ibis@vhdl.org Subject: SCOPE SigNoise (the Cadence PCB analysis program) does allow duplicate names in separate libraries. The user tells SigNoise to load libraries in a specified order, which is the search order also. When a request for a model is received the libraries are searched in order and the first match found is returned. Chris From amuranyi@pcocd2.intel.com Wed Oct 5 08:40:09 1994 Return-Path: Received: from hermes.intel.com by vhdl.vhdl.org (4.1/SMI-4.1/BARRNet) id AA08550; Wed, 5 Oct 94 08:40:09 PDT Received: from pcocd2.intel.com by hermes.intel.com (5.65/10.0i); Wed, 5 Oct 94 08:36:10 -0700 Received: from fsp102 (fsp102.fm.intel.com) by pcocd2.intel.com with SMTP id AA13323 (5.65c/IDA-1.4.4 for ); Wed, 5 Oct 1994 08:36:36 -0700 From: Arpad Muranyi - PCD~ Received: by fsp102 (4.1/FMDT-RS6000) id AA20610; Wed, 5 Oct 94 08:33:42 PDT Date: Wed, 5 Oct 94 08:33:42 PDT Message-Id: <9410051533.AA20610@fsp102> To: ibis@vhdl.org Hi, This is a test message from my UNIX account. Arpad From Arpad_Muranyi@ccm.fm.intel.com Wed Oct 5 08:52:56 1994 Return-Path: Received: from ormail.intel.com by vhdl.vhdl.org (4.1/SMI-4.1/BARRNet) id AA08785; Wed, 5 Oct 94 08:52:56 PDT Received: from relay.jf.intel.com by ormail.intel.com with smtp (Smail3.1.28.1 #12) id m0qsR5x-000MQTC; Wed, 5 Oct 94 00:49 PDT Received: from ccm.hf.intel.com by relay.jf.intel.com (Smail3.1.28.1 #2) id m0qsYaV-000twiC; Wed, 5 Oct 94 08:49 PDT Received: by ccm.hf.intel.com (ccmgate 3.0) Wed, 5 Oct 94 08:49:02 PST Date: Wed, 5 Oct 94 08:49:02 PST From: Arpad Muranyi Message-Id: <941005084902_1@ccm.hf.intel.com> To: ibis@vhdl.org Subject: ignore - test message Text item: Text_1 Hi, This is a test message. Don and I have not received any messages from the reflecor in the last couple of days. This is to check if it still works. Arpad From fkai@dellgate.us.dell.com Wed Oct 5 11:45:21 1994 Return-Path: Received: from dellgate.us.dell.com by vhdl.vhdl.org (4.1/SMI-4.1/BARRNet) id AA09899; Wed, 5 Oct 94 11:45:21 PDT Received: by dellgate.us.dell.com with UUCP (Smail3.1.28.1 #1) id m0qsbLs-000D8UC; Wed, 5 Oct 94 13:46 CDT Message-Id: Date: Wed, 5 Oct 94 13:46 CDT From: fkai@dellgate.us.dell.com (Francis Kai) To: Arpad Muranyi , ibis@vhdl.org Subject: Re: ignore - test message It works. I received both of your messages. Francis Kai From less@metasw.com Wed Oct 5 11:49:09 1994 Return-Path: Received: from metasw.com by vhdl.vhdl.org (4.1/SMI-4.1/BARRNet) id AA09905; Wed, 5 Oct 94 11:49:09 PDT Received: from gaea.meta ([192.0.1.5]) by metasw.com (4.1/SMI-4.1) id AA22290; Wed, 5 Oct 94 11:45:02 PDT Date: Wed, 5 Oct 94 11:45:02 PDT From: less@metasw.com (Les Spruiell) Message-Id: <9410051845.AA22290@metasw.com> To: ibis@vhdl.org Subject: remove me please... Greetings, We at Meta-Software have consolidated operations and only need 1 mail stream from the Ibis refector. Please remove my name from the distribution list as I read the Ibis mail from another source. Thanks, Les Spruiell Meta-Software, Inc. less@metasw.com From kaveh@god.Radius.COM Wed Oct 5 12:37:02 1994 Return-Path: Received: from info.radius.com by vhdl.vhdl.org (4.1/SMI-4.1/BARRNet) id AA10202; Wed, 5 Oct 94 12:37:02 PDT Received: from master.radius.com by info.radius.com (Radius-INC-921203) id AA15081; Wed, 5 Oct 1994 12:33:13 -0700 Received: from god.Radius.COM by master.radius.com (Radius-INC-921203) id AA09808; Wed, 5 Oct 94 12:26:19 PDT Received: by god.Radius.COM (4.1/Radius-INC-921203) id AA17563; Wed, 5 Oct 94 12:33:09 PDT Date: Wed, 5 Oct 94 12:33:09 PDT From: kaveh@god.Radius.COM (Kaveh ) Message-Id: <9410051933.AA17563@god.Radius.COM> To: ibis@vhdl.org Subject: REMOVE ME Please remove my name from Ibis distribution list. thanks kaveh kaveh@radius.com From amuranyi@pcocd2.intel.com Wed Oct 5 12:45:01 1994 Return-Path: Received: from hermes.intel.com by vhdl.vhdl.org (4.1/SMI-4.1/BARRNet) id AA10229; Wed, 5 Oct 94 12:45:01 PDT Received: from pcocd2.intel.com by hermes.intel.com (5.65/10.0i); Wed, 5 Oct 94 12:41:10 -0700 Received: from frx250 (frx250.fm.intel.com) by pcocd2.intel.com with SMTP id AA23385 (5.65c/IDA-1.4.4 for ); Wed, 5 Oct 1994 12:41:37 -0700 From: Arpad Muranyi - PCD~ Received: by frx250 (AIX 3.2/UCB 5.64/FMDT-RS6000) id AA16192; Wed, 5 Oct 1994 12:41:07 -0700 Date: Wed, 5 Oct 1994 12:41:07 -0700 Message-Id: <9410051941.AA16192@frx250> To: ibis@vhdl.org Could someone please check into the status on our addresses? We (Don and myself) have not received anything from the reflector in the last few days, and I know that there is some activity out there. I requested on Monday that our address be changed to have fm instead of hf in it. Did this change cut us off? Was the change done at all? Or, is there another problem, maybe in our mail system? Whoever knows what is going on, please contact me ASAP either on the phone or my UNIX account. These are the two which still seem to work. Phone: (916) 356-2558 Unix: amuranyi@pcocd2.intel.com The reflector addresses should be: Don_A_Telian@ccm.fm.intel.com Arpad_Muranyi@ccm.fm.intel.com Thanks for the help, Arpad From rharr@mojave.stanford.edu Wed Oct 5 13:47:59 1994 Return-Path: Received: from mojave.Stanford.EDU by vhdl.vhdl.org (4.1/SMI-4.1/BARRNet) id AA10619; Wed, 5 Oct 94 13:47:59 PDT Received: by mojave.Stanford.EDU (5.57/Ultrix2.4-C) id AA26906; Wed, 5 Oct 94 13:44:02 PDT Message-Id: <9410052044.AA26906@mojave.Stanford.EDU> X-Sender: randyh@vhdl.vhdl.org Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Date: Wed, 5 Oct 1994 13:41:45 -0800 To: Arpad Muranyi From: rharr@mojave.stanford.edu (Randolph E. "Randy" Harr) Subject: Re: Cc: ibis@vhdl.org As your former list admin and still the overall sysadmin of vhdl.org; I will check into this immediately and get it corrected. Give me a call or email directly if you continue to have any problems. As a reminder for all, email your list server requests (add/delete/modify) to ibis-request@vhdl.org. This avoids junk mail to all the list members. Also, if you think you are not getting the mail anymore, retrieve the file /pub/ibis/email.archive. It contains all messages sent out over the reflector and is a great way to retrieve any old messages you may have missed. This file is reset monthly or so with the old ones going into the email subdirectory. Anonymous FTP, Guest TELNET, or email (archive@vhdl.org) can all be used to retrieve the file. Randy Harr rharr@mojave.stanford.edu >Could someone please check into the status on our addresses? > >We (Don and myself) have not received anything from the >reflector in the last few days, >and I know that there is some activity out there. > >I requested on Monday that our address be changed to have >fm instead of hf in it. Did this change cut us off? >Was the change done at all? >Or, is there another problem, maybe in our mail system? > >Whoever knows what is going on, please contact me ASAP >either on the phone or my UNIX account. These are the >two which still seem to work. > >Phone: (916) 356-2558 >Unix: amuranyi@pcocd2.intel.com > >The reflector addresses should be: > >Don_A_Telian@ccm.fm.intel.com >Arpad_Muranyi@ccm.fm.intel.com > >Thanks for the help, Arpad From Derrick_Duehren@ccm2.jf.intel.com Wed Oct 5 15:42:18 1994 Return-Path: Received: from ormail.intel.com by vhdl.vhdl.org (4.1/SMI-4.1/BARRNet) id AA11432; Wed, 5 Oct 94 15:42:18 PDT Received: from relay.jf.intel.com by ormail.intel.com with smtp (Smail3.1.28.1 #12) id m0qsXU0-000MOjC; Wed, 5 Oct 94 07:38 PDT Received: from ccm.hf.intel.com by relay.jf.intel.com (Smail3.1.28.1 #2) id m0qseyY-000tweC; Wed, 5 Oct 94 15:38 PDT Received: by ccm.hf.intel.com (ccmgate 3.0) Wed, 5 Oct 94 15:38:17 PST Date: Wed, 5 Oct 94 15:38:17 PST From: Derrick Duehren Message-Id: <941005153817_1@ccm.hf.intel.com> To: IBIS@vhdl.org Subject: IBIS 10/7/94 Meeting Agenda Text item: Text_1 IBIS Open Forum Meeting Agenda for 10/7/94 Bridge: Res: (916) 356-9999 394217 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 Spice-to-IBIS converter Ross/Crisafulli 2.0 BNF Rochel 9:00 IBIS General Session/Summit (face-to-face) - In Nov? - At ICDAC? - Possible topics: o 2.1 Ratification o EIA Affiliation o Technology presentations 9:55 Wrap-up, next meeting plans Hobbs From bob@icx.com Tue Oct 11 19:20:21 1994 Return-Path: Received: from uu4.psi.com by vhdl.vhdl.org (4.1/SMI-4.1/BARRNet) id AA25303; Tue, 11 Oct 94 19:20:21 PDT Received: by uu4.psi.com (5.65b/4.0.071791-PSI/PSINet) via UUCP; id AA18216 for ; Tue, 11 Oct 94 22:08:15 -0400 Date: Tue, 11 Oct 94 18:52:14 PDT From: bob@icx.com ( Bob Ross) Received: by icx.com (4.1/3.2.083191-Interconnectix Inc.) id AA10572; Tue, 11 Oct 94 18:52:14 PDT Message-Id: <9410120152.AA10572@icx.com> To: ibis@vhdl.org Subject: MORE BNF FOR IBIS 2.1 Steffen Rochel and Ibis Committee Here is another iteration which has your previously reported correction for pin_mapping_value_set_wr. Further changes include: (1) pin_mapping bus_name introduced to provide for string15 | 'nc' (2) subparameters which are technically case sensitive are listed with the correct case (for example I/O instead of i/o) (3) added v_fixture_min and v_fixture_max Bob Ross Interconnectix, Inc. Previous remarks follow: I have attempted a thorough pass through the BNF. Probably more review is needed for better accuracy. My changes are indicated by a comment above using specific comment format: "//*** ..... " Some minor spelling corrections are not noted. Several overall comments: (1) For certain groups of keywords, the order of occurance is not fixed. I did not make any changes or notes where I detected such situations. However, I did provide the sub-parameter ordering combinations for the sub- parameters r_pin, l_pin, and c_pin since this is the only exception to a fixed keyword-line sub-parameter ordering. (2) At this time the sub-parameters are case sensitive. I did not attempt to make changes in this area. This could be a IBIS issue to relax Version 2.1 over Version 1.1. Reserved words 'power', 'gnd', 'na', 'nc' are not case sensitive. Units, e.g, 'm' are case sensitive. So some portions of the BNF may have to be changed for clarity. Without any case sensitivity restrictions, the BNF here will except IBIS_CHK compliant syntax along with non-compliant case change variations. Other than units and file name conventions, no portion of IBIS really needs the case restriction. (3) The 80 character line length limit is assumed using strings of limited length and reals. However, a sequence of reals may extend over several lines in the "full_matrix" package model. Stings of unlimited length may extend to subsequent lines, and their termination is demarked by any subsequent keyword. //*** Changes in "keywords ... and added next line: // Remarks // comments starts with "//" // keywords are enclosed by '[' '...' ']'. An underbar "_" may be substituted // for any internal single space and a single space may be substituted for // an internal underbar. No space may exist between the '[' or ']' and // the internal keyword. // defined characters and verbatium strings 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' //*** Some comment characters used "\" so I changed the list and //*** put the permitted characters in ASCII order within ' '. comment_character ::= '!' | '"' | '#' | '$' | '%' | '&' | ''' | '(' | ')' | '*' | ',' | ':' | ';' | '<' | '>' | '?' | '@' | '\' | '^' | '`' | '{' | '|' | '}' | '~' ibisfilename ::= '[' 'file name' ']' ibisfilenamestring ibisfilenamestring ::= string8 '.ibs' packagefilename ::= '[' 'file name' ']' packagefilenamestring packagefilenamestring ::= string8 '.pkg' fileversion ::= '[' 'file rev' ']' string date ::= '[' 'date' ']' string40 //*** The following four keywords do not have a string length limitation. //*** Even copyright can extend to several lines. source ::= '[' 'source' ']' string notes ::= '[' 'notes' ']' string disclaimer ::= '[' 'disclaimer' ']' string copyright ::= '[' 'copyright' ']' string 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' //*** This was unclear, so I made a change here //pin_with_package_info pin ::= pin_wpi | pin_data //*** Sub-parameter order choices added pin_wpi ::= pin_header rlc_pin_heading pin_entry_set_wpi rlc_pin_heading ::= 'R_pin' 'L_pin' 'C_pin' | 'R_pin' 'C_pin' 'L_pin' | 'L_pin' 'C_pin' 'R_pin' | 'L_pin' 'R_pin' 'C_pin' | 'C_pin' 'R_pin' 'L_pin' | 'C_pin' 'L_pin' 'R_pin' 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 } //*** Even with package information heading, the last 3 columns are //*** optional for any line. Thus the "[" and "]". pin_entry_wpi ::= pin_entry [ real_na9 real_na9 real_na9 ] //*** model_identifier is required, so I removed the "[" and "]" 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 //*** Last two subparameters are optional and pin_mapping follows similar //*** syntax to diff_pin. This whole section has been modified. //*** bus_name allows 'nc' pin_mapping ::= pin_mapping_wr | pin_mapping_data pin_mapping_wr ::= pin_mapping_header clamp_ref_name pin_mapping_value_set_wr pin_mapping_data ::= pin_mapping_header pin_mapping_value_set pin_mapping_header ::= '[' 'pin mapping' ']' 'pulldown_ref' 'pullup_ref' clamp_ref_name ::= 'gnd_clamp_ref' 'power_clamp_ref' pin_mapping_value_set ::= pin_mapping_values { pin_mapping_values } pin_mapping_value_set_wr ::= pin_mapping_values_wr { pin_mapping_values_wr } pin_mapping_values_wr ::= pin_identifier bus_name bus_name [ bus_name bus_name ] pin_mapping_values ::= pin_identifier bus_name bus_name bus_name ::= string15 | 'nc' // pin_identifer ::= string5 defined previously 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 } //*** Last two entries can be optional 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_refs and voltage_range requirement clarification below: model_range ::= voltage_range | all_model_refs | voltage_range model_refs all_model_refs ::= pullup_reference pulldown_reference gnd_clamp_reference power_clamp_reference 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 //*** Both dvdtr and dvdtf are required 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 //*** Added v_fixture_min and v_fixture_max waveform_header ::= r_fixture v_fixture [ c_fixture ] [ l_fixture ] [ r_dut ] [ l_dut ] [ c_dut ] [v_fixture_min] [v_fixture_max] r_fixture ::= 'R_fixture' '=' real v_fixture ::= 'V_fixture' '=' real v_fixture_min ::= 'V_fixture_min' '=' real v_fixture_max ::= 'V_fixture_max' '=' 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 //*** Insert "number_pins" and "pin_numbers" definition corrected" package_header ::= manufacturer oem description number_pins pin_numbers pin_names oem ::= '[' 'oem' ']' string40 description ::= '[' 'description' ']' string60 //*** Correction here and define "pin_numbers" number_pins ::= '[' 'number of pins' ']' pos_integer pin_numbers ::= '[' 'pin numbers' ']' pin_names 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 ::= '[' 'inductance 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 } //*** Refinded matrix_line definitions for banded and sparce matricies and //*** broke out "row". Corrected bandwidth spelling. banded_matrix ::= 'banded matrix' bandwidth banded_matrix_line { banded_matrix_line } sparse_matrix ::= 'sparse matrix' sparce_matrix_line { sparce_matrix_line } bandwidth ::= '[' 'bandwidth' ']' pos_integer matrix_line ::= row real { real } banded_matrix_line ::= row real sparce_matrix_line ::= row string5 real { string5 real } row ::= '[' 'row' ']' string5 endpackage ::= '[' 'end package model' ']' //*** Made explicit that characters can follow real, certain FIRST characters are //*** Units real ::= [ anychar { anychar } ] real9 ::= //*** Put in extended unit definition using ' ' anychar ::= unit | char unit ::= 'f' | 'p' | 'n' | 'u' | 'm' | 'k' | 'M" | 'G' | 'T' string5 ::= string8 ::= string15 ::= string20 ::= string40 ::= string60 ::= string ::= char ::= pos_integer ::= From bob@icx.com Fri Oct 14 18:40:04 1994 Return-Path: Received: from uu4.psi.com by vhdl.vhdl.org (4.1/SMI-4.1/BARRNet) id AA03541; Fri, 14 Oct 94 18:40:04 PDT Received: by uu4.psi.com (5.65b/4.0.071791-PSI/PSINet) via UUCP; id AA04114 for ; Fri, 14 Oct 94 21:26:53 -0400 Date: Fri, 14 Oct 94 18:15:43 PDT From: bob@icx.com ( Bob Ross) Received: by icx.com (4.1/3.2.083191-Interconnectix Inc.) id AA20993; Fri, 14 Oct 94 18:15:43 PDT Message-Id: <9410150115.AA20993@icx.com> To: 73053.721@compuserve.com, ibis@vhdl.org Subject: IBISCHK2 CORRECTION Paul: One correction to IBISCHK2 is that the model type "3-state" is correct, NOT "3-State". The IBIS Version 2.0 Spec contains an error under the [Model] keyword where it lists "3-State". Version 1.1 and IBIS_CHK are correct in accepting "3-state". Bob Ross Interconnectix, Inc. From schmahl@slszwat Sat Oct 15 06:34:22 1994 Return-Path: Received: from slsa02t.stgl.netd.alcatel.de by vhdl.vhdl.org (4.1/SMI-4.1/BARRNet) id AA10415; Sat, 15 Oct 94 06:34:22 PDT Received: from slssn1t.stgl.sel.alcatel.de by slsa02t.stgl.netd.alcatel.de with SMTP (PP) id <14901-0@slsa02t.stgl.netd.alcatel.de>; Sat, 15 Oct 1994 14:30:51 +0100 Received: from slszwat.stgl.sel.alcatel.de by slssn1t.stgl.sel.alcatel.de (4.1/SMI-4.1-DNI-7.0.1) id AA11435; Sat, 15 Oct 94 14:31:14 +0100 Received: from slszwbt.vs_ehc6 by slszwat.stgl.sel.alcatel.de (4.1/SMI-4.1-DNI) id AA03247; Sat, 15 Oct 94 14:34:13 +0100 Received: by slszwbt.vs_ehc6 (4.1/SMI-4.1-DNI-7.0.1) id AA01481; Sat, 15 Oct 94 14:34:15 +0100 Date: Sat, 15 Oct 1994 14:28:46 +0100 (MET) From: Gerhard Schmahl Subject: Remove me please ... To: ibis@vhdl.org Cc: Albrecht Reiber Message-Id: Mime-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Gentlemen, thank you for having me included in your information loop so far. As Albrecht Reiber (see cc:) a team-member of mine is already in your mail stream, please remove me from the IBIS reflector. Thanks and best regards, Gerhard Schmahl ======================================================================= Gerhard Schmahl Phone: (+49) 711 821 - 5526 Alcatel SEL AG Fax: (+49) 711 821 - 5551 Dept. VS/EHC6 Internet: GSchmahl@stgl.sel.alcatel.de Lorenzstrasse 10 70435 Stuttgart, Germany =========================== End of Email ============================== From Will_Hobbs@ccm2.jf.intel.com Mon Oct 17 14:13:31 1994 Return-Path: Received: from ormail.intel.com by vhdl.vhdl.org (4.1/SMI-4.1/BARRNet) id AA12208; Mon, 17 Oct 94 14:13:31 PDT Received: from relay.jf.intel.com by ormail.intel.com with smtp (Smail3.1.28.1 #12) id m0qwzK2-000MQ8C; Mon, 17 Oct 94 14:10 PDT Received: from ccm.jf.intel.com by relay.jf.intel.com (Smail3.1.28.1 #2) id m0qwzJD-000tweC; Mon, 17 Oct 94 14:09 PDT Received: by ccm.jf.intel.com (ccmgate 3.0) Mon, 17 Oct 94 14:09:31 PST Date: Mon, 17 Oct 94 14:09:31 PST From: Will Hobbs Message-Id: <941017140931_4@ccm.jf.intel.com> To: ibis@vhdl.org Subject: Bridge numbers for next 3 meetings Text item: Text_1 Greetings Forum Folk, Here are the bridge numbers for the next 3 IBIS Open Forum phone conferences: All meetings are 8:00 - 10:00 AM Pacific Time (PST or PDT depending on time of year.) 10/28 (916) 356-9999, Reservation Number 406222 11/18 (916) 356-9999, Reservation Number 406223 12/9 (916) 356-9999, Reservation Number 406224 Call the number listed, and when the bridge operator answers, ask for the IBIS Open Forum and reference the reservation number. Incidentally, the more I reflect on it, the more I feel we should try to ratify 2.1 in December. I recommend we make plans to meet face-to-face at that time, rather than waiting until January. Holidays are a problem, but so is lost momentum. Any comments? Regards, Will Hobbs Intel Corp. From huq@rockie.nsc.com Mon Oct 17 15:28:27 1994 Return-Path: Received: from gatekeeper.nsc.com by vhdl.vhdl.org (4.1/SMI-4.1/BARRNet) id AA13088; Mon, 17 Oct 94 15:28:27 PDT Received: from nsc.nsc.com by gatekeeper.nsc.com (5.65/fma-120691) with SMTP; id AA29218 for ibis@vhdl.org; Mon, 17 Oct 94 15:24:31 -0700 Received: from lightning.nsc.com by nsc.nsc.com (5.65/1.34) with SMTP id AA07892 for ibis@vhdl.org; Mon, 17 Oct 94 15:24:29 -0700 Received: from kural by rockie.nsc.com (4.1/SMI-4.1) id AA24192; Mon, 17 Oct 94 15:26:45 PDT Date: Mon, 17 Oct 94 15:26:45 PDT From: huq@rockie.nsc.com (Syed Huq) Message-Id: <9410172226.AA24192@rockie.nsc.com> To: ibis@vhdl.org Subject: IBIS library Hi Michael Steer, Got a question for you. Is there any way to monitor how many times a model gets copied out of vhdl.org or 'who' copies models out of the model dir. As we release more and more models, I was just wondering if there is a way to know this information thru some log file... Sometimes, management wants to know.. Regards, Syed Huq National Semiconductor. From bob@icx.com Mon Oct 17 16:34:10 1994 Return-Path: Received: from uu4.psi.com by vhdl.vhdl.org (4.1/SMI-4.1/BARRNet) id AA13928; Mon, 17 Oct 94 16:34:10 PDT Received: by uu4.psi.com (5.65b/4.0.071791-PSI/PSINet) via UUCP; id AA17640 for ; Mon, 17 Oct 94 19:08:14 -0400 Date: Mon, 17 Oct 94 15:51:24 PDT From: bob@icx.com ( Bob Ross) Received: by icx.com (4.1/3.2.083191-Interconnectix Inc.) id AA26607; Mon, 17 Oct 94 15:51:24 PDT Message-Id: <9410172251.AA26607@icx.com> To: ibis@vhdl.org Subject: IBIS SUMMIT Will and IBIS Committee: I support your desire to have the IBIS SUMMIT face-to-face meeting in December. Based on discussions to date, the IBIS Version 2.1 document will have only a few changes and text corrections. Based on some initial testing on some large IBIS Version 2.0 model files, the ibischk2 parser seems to function very well. It does have a few easily correctable problems, and I feel that it should be in good shape by December with the inclusion of some missing functionality. Besides maintaining momentum, one advantage of a December meeting is that possible EIA standard balloting activity can probably be funded through the DIE ARPA funding. Because of this possible direction, I would like to see the SUMMIT meeting in the early part of December so that the administrative preparations can occur in a careful and timely manner. Bob Ross Interconnectix, Inc. From Will_Hobbs@ccm2.jf.intel.com Mon Oct 17 16:55:16 1994 Return-Path: Received: from ormail.intel.com by vhdl.vhdl.org (4.1/SMI-4.1/BARRNet) id AA14065; Mon, 17 Oct 94 16:55:16 PDT Received: from relay.jf.intel.com by ormail.intel.com with smtp (Smail3.1.28.1 #12) id m0qx1qX-000MRAC; Mon, 17 Oct 94 16:52 PDT Received: from ccm.jf.intel.com by relay.jf.intel.com (Smail3.1.28.1 #2) id m0qx1pi-000tweC; Mon, 17 Oct 94 16:51 PDT Received: by ccm.jf.intel.com (ccmgate 3.0) Mon, 17 Oct 94 16:51:13 PST Date: Mon, 17 Oct 94 16:51:13 PST From: Will Hobbs Message-Id: <941017165113_3@ccm.jf.intel.com> To: huq@rockie.nsc.com, ibis@vhdl.org Subject: Re: IBIS library Text item: Just a thought.... A simple checkout command could be part of the model downloading process, and part of it would save the user id and the models to a file. Will Hobbs Intel Corp. Hi Michael Steer, Got a question for you. Is there any way to monitor how many times a model gets copied out of vhdl.org or 'who' copies models out of the model dir. As we release more and more models, I was just wondering if there is a way to know this information thru some log file... Sometimes, management wants to know.. 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: IBIS library To: ibis@vhdl.org Message-Id: <9410172226.AA24192@rockie.nsc.com> From: huq@rockie.nsc.com (Syed Huq) Date: Mon, 17 Oct 94 15:26:45 PDT Received: from kural by rockie.nsc.com (4.1/SMI-4.1) id AA24192; Mon, 17 Oct 94 15:26:45 PDT Received: from lightning.nsc.com by nsc.nsc.com (5.65/1.34) with SMTP id AA07892 for ibis@vhdl.org; Mon, 17 Oct 94 15:24:29 -0700 Received: from nsc.nsc.com by gatekeeper.nsc.com (5.65/fma-120691) with SMTP; id AA29218 for ibis@vhdl.org; Mon, 17 Oct 94 15:24:31 -0700 Received: from gatekeeper.nsc.com by vhdl.vhdl.org (4.1/SMI-4.1/BARRNet) id AA13088; Mon, 17 Oct 94 15:28:27 PDT Received: from vhdl.vhdl.org by hermes.intel.com (5.65/10.0i); Mon, 17 Oct 94 15 Received: from hermes by ichips.intel.com (5.64+/10.0i); Mon, 17 Oct 94 15:34:18 Received: from ichips.intel.com by relay.jf.intel.com with smtp (Smail3.1.28.1 #2) id m0qx0f2-000tweC; Mon, 17 Oct 94 15:36 PDT From mbs@eos.ncsu.edu Tue Oct 18 05:53: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 AA22343; Tue, 18 Oct 94 05:53:02 PDT Received: by mbs.ece.ncsu.edu (5.65/Eos/C-U-09Sep93) id AA08226; Tue, 18 Oct 1994 08:49:00 -0400 From: mbs@eos.ncsu.edu Message-Id: <9410181249.AA08226@mbs.ece.ncsu.edu> To: huq@rockie.nsc.com (Syed Huq) To: ibis@vhdl.org Subject: Re: IBIS library Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Date: Tue, 18 Oct 94 08:48:59 EDT Syed at. al, Syed writes ... > Hi Michael Steer, > Got a question for you. Is there any way to monitor how many times > a model gets copied out of vhdl.org or 'who' copies models out > of the model dir. > > As we release more and more models, I was just wondering if there is > a way to know this information thru some log file... > This information is recorded now in a condensed format. I will see what we can do to refine the information. I will get back to you shortly. We are still waiting on a legal O.K. on the disclaimer (any news Derrick ?) Michael Steer ***************************************************************************** Dr. Michael Steer mbs@ncsu.edu Associate Professor 919-515-5191 Electrical and Computer Engineering Department 919-515-5523 (fax) North Carolina State University, Raleigh, NC 27695-7911 From bob@icx.com Tue Oct 18 11:27:22 1994 Return-Path: Received: from uu4.psi.com by vhdl.vhdl.org (4.1/SMI-4.1/BARRNet) id AA24372; Tue, 18 Oct 94 11:27:22 PDT Received: by uu4.psi.com (5.65b/4.0.071791-PSI/PSINet) via UUCP; id AA20474 for ; Tue, 18 Oct 94 13:57:09 -0400 Date: Tue, 18 Oct 94 10:39:11 PDT From: bob@icx.com ( Bob Ross) Received: by icx.com (4.1/3.2.083191-Interconnectix Inc.) id AA29068; Tue, 18 Oct 94 10:39:11 PDT Message-Id: <9410181739.AA29068@icx.com> To: 73053.721@compuserve.com, ibis@vhdl.org Subject: Forwarded: Question Paul, I am posting your question to the IBIS committee for input. For me, (2) would be nice, but not required. Preferences?? Bob Bob, The original message is telling you that no more memory can be allocated, so, yes you are running out of memory. The IBISCHK2 program is not size constrianed; it will try to allocate as much memory as it needs in order to save the contents of the file in memory. For the purpose of successfully completing the parsing, maybe we should just give a warning once all the memory is used, and then forget about trying to save anything after that. Unfortunately, the saved contents often serve for later validation. So this leaves us with 2 options: 1) Require the machine to have sufficient memory, or 2) allow the golden parser to accept a flag that tells it to run in a conservative mode (probably free memory as soon as it can and forget about anyone trying to use the structure contents later on). We're open for suggestions. Paul Munsey ---- Your message ---- Paul When I use IBISCHK2 on a large IBIS file containing all of the parts in a design (750K) I get around approximately line 5960: PROGRAM BUG - Unabel t Allocate Memory: c:\ibis\v2\src\rngp.c 192 and later, other similar messages and eventually an abnormal termination with c:\ibis\v2\src\mdl.c:727:assertion failed. Am I running out of memory or is the IBISCHK2 program size constrained? Bob Ross, Interconnectix, Inc. From bracken@bacon.performance.com Tue Oct 18 12:21:33 1994 Return-Path: Received: from bacon.performance.com by vhdl.vhdl.org (4.1/SMI-4.1/BARRNet) id AA24722; Tue, 18 Oct 94 12:21:33 PDT Received: from localhost (bracken@localhost) by bacon.performance.com (8.6.9/8.6.9) with ESMTP id PAA14932 for ; Tue, 18 Oct 1994 15:20:46 -0400 Message-Id: <199410181920.PAA14932@bacon.performance.com> To: ibis@vhdl.org Subject: Re: Size limit In-Reply-To: Your message of "Tue, 18 Oct 1994 10:39:11 PDT." <9410181739.AA29068@icx.com> Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Id: <14930.782508045.1@bacon.performance.com> Date: Tue, 18 Oct 1994 15:20:46 -0400 From: "J. Eric Bracken" >> When I use IBISCHK2 on a large IBIS file containing all of the parts >> in a design (750K) I get around approximately line 5960: >> >> PROGRAM BUG - Unabel t Allocate Memory: c:\ibis\v2\src\rngp.c 192 On what kind of machine (and with how much real memory/swap) is this error message being produced? If it's a PC, could the problem related to certain addressing limitations of DOS? --Eric From Derrick_Duehren@ccm2.jf.intel.com Tue Oct 18 12:53:11 1994 Return-Path: Received: from ormail.intel.com by vhdl.vhdl.org (4.1/SMI-4.1/BARRNet) id AA25009; Tue, 18 Oct 94 12:53:11 PDT Received: from relay.jf.intel.com by ormail.intel.com with smtp (Smail3.1.28.1 #12) id m0qxKXn-000MRLC; Tue, 18 Oct 94 12:49 PDT Received: from ccm.hf.intel.com by relay.jf.intel.com (Smail3.1.28.1 #2) id m0qxKX0-000twfC; Tue, 18 Oct 94 12:49 PDT Received: by ccm.hf.intel.com (ccmgate 3.0) Tue, 18 Oct 94 12:49:10 PST Date: Tue, 18 Oct 94 12:49:10 PST From: Derrick Duehren Message-Id: <941018124910_1@ccm.hf.intel.com> To: Randy_L_Wilhelm@ccm.fm.intel.com, Jerry_Budelman@ccm2.jf.intel.com, IBIS@vhdl.org Subject: IBIS 10/7/94 Meeting Minutes Text item: Text_1 Date: Oct. 17, 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 10/7/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* 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 Stanford University Randy Harr Symmetry Martin Walker Synopsys, Logic Modeling G. Bill Lattin Texas Instruments Bob Ward Thomson-CSF/SCTF Jean Lebrun UniCAD Canada Ltd. Stephen Lum Zeelan Technology George Opsahl, Hiro Moriyasu Mon Seng(?), Stree Co. 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 # 10/28/94 (916) 356-9999 406222 11/18/94 (916) 356-9999 406223 12/9/94 (916) 356-9999 406224 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. ------------------------------------------------------------------------ Check-in, Intros, Announcements A new person joined us, Mon Seng(sp?), of Stree Co., Santa Clara, which makes graphics accelerators. There were no corrections made to last month's minutes. AR Mon, send your email address to Derrick (address above). AR Derrick: Mail last meeting minutes to Mon. So far, 5 companies have paid for the 2.0 parser. HP, HyperLynx, Quad Design, Interconnectix, and Intel. Four others reported having the paperwork in process. New Agenda Items: Scope, Non-monotonic data Press Updates: IBIS was mentioned in a paper and seminar that Ravender presented at ISHM/ Nordic in Finland this week attended by more than 150 technical experts from Nordic and other European countries. The IBIS overview article has been approved by Intel Legal and should be able to be forwarded to EDN next week. Nikkei Press Editor asked Will for an update on Version 2.0. AR Will/Derrick: Draft a press release with current status. Progress toward enlisting new IC vendors Intel960 family IBIS models are now available through Intel's American Marketing Organization bulletin board and Intel's sales force. When they are fully validated, Intel will post them to vhdl.org. Syed posted a sample 2.0 model to vhdl.org. Golden Parser, 2.0 Paul reported that he has draft 2.0 parser disks ready. Will will mail them out on Monday. Source and PC-executable files are included. The readme file contains instructions for building the parser. This Beta release is for a 6-week review. V1.0 regression testing has yet to be done. AR Beta Users: Run as many IBIS 1.1 and 2.0 files as possible. Jon Powell volunteered to create a Sun version. Will will send Jon the approved distribution list. Several other formats were volunteered. AR Paul: Give the parser a unique name, such as IBIS_CK2, and forward the files to Will. [Done] NOTE: The sooner that Paul receives feedback, the sooner he can revise the parser and send it out for further review. IBIS Librarian PC version of Spice-to-IBIS "lost" on vhdl.org. The group discussed timeliness of responses to vhdl.org requests. AR Michael Steer: Please post a note to the reflector indicating the typical responsiveness we can expect from the librarian. Spice-to-IBIS Converter Interconnectix has used the converter to make commercial IBIS files. Bob told of problems in the [Pull-up] table section. The data tended to become nonmonotonic at the ends. 2.0 BNF Bob Ross plans to post an update next week. Done. IBIS General Session (face-to-face) Will proposed that we have our next face-to-face meeting the day after ICCAD, Friday November 11th in San Jose. However, the Beta test won't be done. We agreed that we need at least 10 test models to properly test the parser. We decided to postpone the meeting until January. We will schedule it at our next meeting. Agenda suggestions: o 2.1 Ratification o EIA Affiliation o Technology presentations Update: Will proposes scheduling the general session for early December to maintain momentum. Monotonicity We agreed that our intention is that there can be parts that are non-monotonic. The 2.0 spec has an erroneous line that was never intended. Kellee volunteer to write BIRD 20 to make the spec more like the original passed BIRD 8.2. We agreed to implement BIRD 20 in the draft parser with the expectation that it will be approved at our next meeting. AR Kellee: Post BIRD 20 and communicate the changes to Paul Munsey. Scope We agreed that each file has its own syntactic scope. Wrap-up, Next Meeting Plans Our next meeting is 10/28/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 (415-335-0110), or send an email request to the automatic archive server, archive@vhdl.org. ============================================================================== From bob@icx.com Tue Oct 18 16:39:26 1994 Return-Path: Received: from uu4.psi.com by vhdl.vhdl.org (4.1/SMI-4.1/BARRNet) id AA26522; Tue, 18 Oct 94 16:39:26 PDT Received: by uu4.psi.com (5.65b/4.0.071791-PSI/PSINet) via UUCP; id AA26816 for ; Tue, 18 Oct 94 19:08:06 -0400 Date: Tue, 18 Oct 94 15:54:45 PDT From: bob@icx.com ( Bob Ross) Received: by icx.com (4.1/3.2.083191-Interconnectix Inc.) id AA00309; Tue, 18 Oct 94 15:54:45 PDT Message-Id: <9410182254.AA00309@icx.com> To: 75053.731@compuserve.com, ibis@vhdl.org Subject: Re: Size limit Eric Bracken: I used a PC with just plain DOS and about 2M of free disk space and 300K of extended memory. So I expected some problems. When the file was designated as Version 1.1, ibischk2 completed the checking. When the file was designated 2.1, the memory error below was produced. When ibischk2 was compiled on a workstation and the same file was tested, the program completed the checking for both cases. I don't know if DOS has addressing limits which limits the size of a file that ibischk2 can handle. Paul, can you answer this? Bob Ross, Interconnectix, Inc. > >> When I use IBISCHK2 on a large IBIS file containing all of the parts > >> in a design (750K) I get around approximately line 5960: > >> > >> PROGRAM BUG - Unabel t Allocate Memory: c:\ibis\v2\src\rngp.c 192 > On what kind of machine (and with how much real memory/swap) is this error > message being produced? > If it's a PC, could the problem related to certain addressing limitations > of DOS? > --Eric From 73053.721@compuserve.com Tue Oct 18 22:21:22 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 AA28708; Tue, 18 Oct 94 22:21:22 PDT Received: from localhost by dub-img-2.compuserve.com (8.6.4/5.940406sam) id BAA03787; Wed, 19 Oct 1994 01:17:25 -0400 Date: 19 Oct 94 01:14:37 EDT From: Paul Munsey <73053.721@compuserve.com> To: IBIS Reflector Cc: Ron Neville <75123.3477@compuserve.com> Subject: Re: Size limit Message-Id: <941019051436_73053.721_GHB28-3@CompuServe.COM> Bob Ross, I'm not a DOS memory pro, but what I read is that a large memory model should handle multiple data segments (64K). It could be that Ron and I accidentally switched the memory model for the executable we shipped, but I highly doubt it. A reason the file worked as a 1.1 and not as a 2.0 could be because much less information is held in the 1.1 structures. Currently the ibis_chk2 program just has the 1.1 code compiled in without trying to use the 2.0 memory structures and allocation. To find out if we're working with a DOS limitation we could just try the file on a PC with more memory. If someone wants to mail me the file I'll be glad to work with it and see what problems I get. Paul Munsey ---------- Forwarded Message ---------- From: INTERNET:bob@icx.com, INTERNET:bob@icx.com TO: Paul Munsey, 73053,721 (unknown), 71436,1314 (unknown), 74012,21 DATE: 10/18/94 4:45 PM RE: +Postage Due+Re: Size limit Sender: bob@icx.com Received: from vhdl.vhdl.org by dub-img-2.compuserve.com (8.6.4/5.940406sam) id TAA23338; Tue, 18 Oct 1994 19:38:54 -0400 Received: from uu4.psi.com by vhdl.vhdl.org (4.1/SMI-4.1/BARRNet) id AA26522; Tue, 18 Oct 94 16:39:26 PDT Received: by uu4.psi.com (5.65b/4.0.071791-PSI/PSINet) via UUCP; id AA26816 for ; Tue, 18 Oct 94 19:08:06 -0400 Date: Tue, 18 Oct 94 15:54:45 PDT From: bob@icx.com ( Bob Ross) Received: by icx.com (4.1/3.2.083191-Interconnectix Inc.) id AA00309; Tue, 18 Oct 94 15:54:45 PDT Message-Id: <9410182254.AA00309@icx.com> To: 75053.731@compuserve.com, ibis@vhdl.org Subject: Re: Size limit Eric Bracken: I used a PC with just plain DOS and about 2M of free disk space and 300K of extended memory. So I expected some problems. When the file was designated as Version 1.1, ibischk2 completed the checking. When the file was designated 2.1, the memory error below was produced. When ibischk2 was compiled on a workstation and the same file was tested, the program completed the checking for both cases. I don't know if DOS has addressing limits which limits the size of a file that ibischk2 can handle. Paul, can you answer this? Bob Ross, Interconnectix, Inc. > >> When I use IBISCHK2 on a large IBIS file containing all of the parts > >> in a design (750K) I get around approximately line 5960: > >> > >> PROGRAM BUG - Unabel t Allocate Memory: c:\ibis\v2\src\rngp.c 192 > On what kind of machine (and with how much real memory/swap) is this error > message being produced? > If it's a PC, could the problem related to certain addressing limitations > of DOS? > --Eric From cer@Cadence.COM Wed Oct 19 06:39:09 1994 Return-Path: Received: from mailgate.cadence.com by vhdl.vhdl.org (4.1/SMI-4.1/BARRNet) id AA05010; Wed, 19 Oct 94 06:39:09 PDT Received: (from smap@localhost) by mailgate.cadence.com (8.6.8/8.6.8) id GAA01826 for ; Wed, 19 Oct 1994 06:35:06 -0700 Received: from cadence.cadence.com(158.140.18.1) by mailgate.cadence.com via smap (V1.0mjr) id sma001743; Wed Oct 19 06:34:09 1994 Received: from oahu by cadence.Cadence.COM (5.61/3.14) id AA15496; Wed, 19 Oct 94 06:31:05 -0700 Received: by oahu (5.65+/1.5) id AA10108; Wed, 19 Oct 94 09:34:26 -0400 Date: Wed, 19 Oct 94 09:34:26 -0400 From: cer@cadence.com (Chrisopher E. Reid) Message-Id: <9410191334.AA10108@oahu> To: ibis@vhdl.org Subject: DOS Memory Models Hello, DOS is really arcane. To clear the confusion on DOS memory models here are the facts about DOS memory models: Addressing Scheme Model Data Code Huge 20 bits 16 + 4 Large 16 + 4 16 + 4 Medium 16 + 4 16 Small 16 16 In the huge model the addressing is always 20 bits for data (1 Megabyte) and segmented (16 + 4) for code. The segmentation means there are 20 effective address bits, but they are split across two 16-bit words with the high 4 bits in a second word. In the Huge model these 20 bits are handled as one unit for data. Actually it is even worse because the segment address is a full 16 bit word addressing memory in 16-byte chunks. The offset is another full 16 bit word which gives the offset from the segment address. Thus there are many possible addresses for the same location. In the Large model the same 20 bits are used, but the 16 bit offset and 4 bit segment portions are independent of eachother. Effectively this means that any one segment can hold at most 64 KB. An overflow of the 16 bit offset portion does NOT change the segment portion, it is simply an overflow. The Huge model fixes this, but it is slower because every time pointer arithmetic is performed a special routine must be called to take care of possible overflow. Finally, in standard old DOS no program can access more than 640K in any case. Windows 3.1 allows access to 16 Megabytes, but that takes special coding by the programmer. Windows 3.1 with the Win32s extensions provides a flat 32-bit memory space and makes 4.4 gigabytes available without special coding. Most machines do not have that much memory. Windows NT and Chicago (Windows 95) both support a flat 32-bit memory space. In short: Yes, I'm sure the problems with the parser are memory limitations imposed by DOS. Chris From 73053.721@compuserve.com Fri Oct 21 23:24:18 1994 Return-Path: <73053.721@compuserve.com> Received: from dub-img-1.compuserve.com by vhdl.vhdl.org (4.1/SMI-4.1/BARRNet) id AA08783; Fri, 21 Oct 94 23:24:18 PDT Received: from localhost by dub-img-1.compuserve.com (8.6.4/5.940406sam) id CAA04900; Sat, 22 Oct 1994 02:20:15 -0400 Date: 22 Oct 94 02:17:46 EDT From: Paul Munsey <73053.721@compuserve.com> To: IBIS Reflector Cc: Ron Neville <75123.3477@compuserve.com> Subject: Waveforms & memory Message-Id: <941022061746_73053.721_GHB48-1@CompuServe.COM> Stephen, Big booboo on this one. You are completely correct on the waveform problems. I think I can safely say that most if not all waveform testing will be useless. I looked in the sources that were used to build the beta and found a mistake that didn't exist in a copy from a few days earlier. I guess one of those last minute cut and pastes didn't do what I hoped. It's fixed now; maybe we should talk in Friday's meeting about another beta. On another topic, I tried your 82378zb.ibs file on my PC and it worked fine (with the exception of the 2 3-State errors). I tried it with the same ibis_chk.exe that was sent with beta. I have a 386 with 8MB of memory and plenty of disk space. This makes me curious if the same executable is failing on your PC (with 16MB) and not on mine (with 8MB). Any clues anyone? I'd be interested in getting Bob Ross's larger file and seeing what happens. Paul Munsey ---------------------------------------------------------------------------------------- To: 73053.721@compuserve.com Cc: Will_Hobbs@ccm2.jf.intel.com Subject: Rising/Falling waveform tables Date: Thu, 20 Oct 1994 18:00:02 -0700 From: Stephen Peters Hello Paul: I been doing some testing with the rising falling waveform tables and it appears that the parser is not recognizing the R_fixture and V_fixture subparamters. Specifically I get the following error messages: Checking test.ibs for IBIS 2.0 Compatibility... ERROR - R_fixture Not Defined For Waveform Beginning on Line 111 ERROR - V_fixture Not Defined For Waveform Beginning on Line 111 ERROR - R_fixture Not Defined For Waveform Beginning on Line 126 ERROR - V_fixture Not Defined For Waveform Beginning on Line 126 c:\ibis\v2\src\cmn.c:267:assertion failed. (Also, note that the line count is wrong, the table ENDS at line 111.) I've enclosed a test file that you can use. Thanks for your help. Best Regards, Stephen From Derrick_Duehren@ccm2.jf.intel.com Wed Oct 26 11:27:10 1994 Return-Path: Received: from ormail.intel.com by vhdl.vhdl.org (4.1/SMI-4.1/BARRNet) id AA06150; Wed, 26 Oct 94 11:27:10 PDT Received: from relay.jf.intel.com by ormail.intel.com with smtp (Smail3.1.28.1 #13) id m0r0D0Z-000MPOC; Wed, 26 Oct 94 11:23 PDT Received: from ccm.hf.intel.com by relay.jf.intel.com (Smail3.1.28.1 #2) id m0r0D04-000twiC; Wed, 26 Oct 94 11:23 PDT Received: by ccm.hf.intel.com (ccmgate 3.0) Wed, 26 Oct 94 11:23:02 PST Date: Wed, 26 Oct 94 11:23:02 PST From: Derrick Duehren Message-Id: <941026112302_1@ccm.hf.intel.com> To: ibis@vhdl.org Subject: 10/28/94 IBIS Agenda Text item: Text_1 IBIS Open Forum Meeting Agenda for 10/28/94 Bridge: Res: (916) 356-9999 406222 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 + Communication approval process (Derrick) - New models available 8:20 Progress toward enlisting new IC vendors All Golden Parser, 2.1 Hobbs - Test Results, updates, actions required Spice-to-IBIS converter Ross/Crisafulli 2.0 BNF Ross 9:00 BIRD 20, Monotonicity Crisafulli 9:15 IBIS General Session/Summit (face-to-face) Hobbs - Date (Will proposes December) - Location (Intel offers Santa Clara) - Proposed topics: o 2.1 Ratification o EIA Affiliation o Technology presentations 9:55 Wrap-up, next meeting plans Hobbs From huq@rockie.nsc.com Thu Oct 27 14:06:14 1994 Return-Path: Received: from gatekeeper.nsc.com by vhdl.vhdl.org (4.1/SMI-4.1/BARRNet) id AA19729; Thu, 27 Oct 94 14:06:14 PDT Received: from nsc.nsc.com by gatekeeper.nsc.com (5.65/fma-120691) with SMTP; id AA21180 for ibis@vhdl.org; Thu, 27 Oct 94 14:02:11 -0700 Received: from lightning.nsc.com by nsc.nsc.com (5.65/1.34) with SMTP id AA29729 for ibis@vhdl.org; Thu, 27 Oct 94 14:02:10 -0700 Received: from kural by rockie.nsc.com (4.1/SMI-4.1) id AA11431; Thu, 27 Oct 94 14:04:29 PDT Date: Thu, 27 Oct 94 14:04:29 PDT From: huq@rockie.nsc.com (Syed Huq) Message-Id: <9410272104.AA11431@rockie.nsc.com> To: ibis@vhdl.org Subject: v2.0 Differential Driver model ready Cc: cjfgsc@tevm2.nsc.com Hi, I have a v2.0 Differential Driver model available for verification only by Simulation vendors. I have passed this to some companies on a request basis only. Once I get some feedback, it will be offically released to the IBIS forum. By end Nov, I will also pass around a v2.0 Differential Receiver model. Pls note that I will be on vacation from Oct28th-Nov20th So..... Talk to guys when I return. Regards, Syed Huq National Semiconductor. From ees!steffen@uunet.uu.net Thu Oct 27 15:07:16 1994 Return-Path: Received: from relay3.UU.NET by vhdl.vhdl.org (4.1/SMI-4.1/BARRNet) id AA20068; Thu, 27 Oct 94 15:07:16 PDT Received: from uucp3.UU.NET by relay3.UU.NET with SMTP id QQxnme27008; Thu, 27 Oct 1994 18:02:26 -0400 Received: from ees.UUCP by uucp3.UU.NET with UUCP/RMAIL ; Thu, 27 Oct 1994 18:02:33 -0400 Received: from booboo.noname by ees. (4.0/SMI-4.0) id AA03515; Thu, 27 Oct 94 13:22:09 PDT Date: Thu, 27 Oct 94 13:22:09 PDT From: ees!steffen@uunet.uu.net Message-Id: <9410272022.AA03515@ees.> To: uunet!vhdl.org!ibis@uunet.uu.net Subject: BNF 2.1 Bob Ross and the Ibis Committee according the updated BNF, I see the following problem: As far I understand the IBIS specification for version2.0, there is no restriction about the placement for different keywords,e.g. one vendor could put the [File name] after the component description. This would be in accordance to the Ibis specification, but not be covered by the BNF. Question for me is now, what is more efficient, to put more restrictions in the Ibis description or to modify the BNF. More restrictions would be more logical for me, because I don't see the necessarity to allow the specification of [Source] etc. after component description, but this could bring up problems according the backward compatibility. Otherwise the BNF would consist mainly of a list of different keywords and the natural structure in a header and description section would be destroyed. What is your oppinion? Steffen Rochel Anacad EES PS: I'm relocating to our US office, so I hope to attend some other meetings. From Will_Hobbs@ccm2.jf.intel.com Thu Oct 27 23:30:12 1994 Return-Path: Received: from relay2.UU.NET by vhdl.vhdl.org (4.1/SMI-4.1/BARRNet) id AA23230; Thu, 27 Oct 94 23:30:12 PDT Received: from ormail.intel.com by relay2.UU.NET with SMTP id QQxnnl05382; Fri, 28 Oct 1994 02:26:02 -0400 Received: from relay.jf.intel.com by ormail.intel.com with smtp (Smail3.1.28.1 #7) id m0r0klG-000UdOC; Thu, 27 Oct 94 23:26 PDT Received: from ccm.jf.intel.com by relay.jf.intel.com (Smail3.1.28.1 #2) id m0r0klG-000tweC; Thu, 27 Oct 94 23:26 PDT Received: by ccm.jf.intel.com (ccmgate 3.0) Thu, 27 Oct 94 23:26:02 PST Date: Thu, 27 Oct 94 23:26:02 PST From: Will Hobbs Message-Id: <941027232602_1@ccm.jf.intel.com> To: uunet!vhdl.org!ibis@uunet.uu.net, steffen%ees@uunet.uu.net Subject: BNF 2.1 Steffen, Since the BNF is derivative, and backward compatibility between IBIS 2.0 and IBIS 1.1 is our commitment, I would not favor modifying the spec to match the BNF. Will From 71436.1314@compuserve.com Fri Oct 28 00:53:49 1994 Return-Path: <71436.1314@compuserve.com> Received: from arl-img-2.compuserve.com by vhdl.vhdl.org (4.1/SMI-4.1/BARRNet) id AA23701; Fri, 28 Oct 94 00:53:49 PDT Received: from localhost by arl-img-2.compuserve.com (8.6.4/5.940406sam) id DAA05743; Fri, 28 Oct 1994 03:04:40 -0400 Date: 28 Oct 94 03:01:27 EDT From: Kellee Crisafulli <71436.1314@compuserve.com> To: IBIS ALL Subject: Resending Bird20, from Kellee Crisafulli Message-Id: <941028070127_71436.1314_HHB36-1@CompuServe.COM> From: Kellee Crisafulli To: IBIS community Re: Bird 20.0 Date: 10-10-94 ) ) ) ) \ \ \ \ \ \ ^^^^^ o o ( \___/ Have a sunny day....Kellee ******************************************************************************* ******************************************************************************* Buffer Issue Resolution Document (BIRD) BIRD ID#: 20.0 ISSUE TITLE: Error correction regarding monotonicity statement in V2.1 IBIS specification. REQUESTOR: Kellee Crisafulli, HyperLynx Inc. DATE SUBMITTED: 10-10-94 DATE REVISED: TBD DATE ACCEPTED BY IBIS OPEN FORUM: TBD ******************************************************************************* ******************************************************************************* STATEMENT OF THE ISSUE: There are two errors in the IBIS version 2.1 specification regarding monotonicity. During the meeting on 10-7-94 the IBIS forum agreed to change the specification to correct these errors. ******************************************************************************* STATEMENT OF THE RESOLVED SPECIFICATIONS: The following changes apply to version 2.1 of the specification and IBIS_CHK program. *************************************************************************** Change 1- Delete the note about 'non-monotonic in one axis' *************************************************************************** In the section defining the keywords [Pulldown], [Pullup], [GND Clamp], [POWER Clamp] and following the paragraph titled "Monotonicity Requirements" the following note is present: | Note that the above conditions allow the data to be | non-monotonic in one axis. The above two lines shall be deleted from the specification. *************************************************************************** Change 2- Add two paragraphs from BIRD 8.2 *************************************************************************** Add the following two paragraphs where the sentence from change 1 above is removed. This is not an error or even a warning. It was down-graded to a simple NOTE: in BIRD 8.2 * * The IBIS_CHK program will test for non-monotonic data and * provide a maximum of one note per V/I table if non-montonic * data is found. For example: * "NOTE: Line 300, Pulldown V/I table for model DC040403 is * non-monotonic! Most simulators will filter this data * to remove the non-monotonic data." * * It is also recognized that the some data may be monotonic if * currents from both the output stage and the clamp diode are * added together as most simulators do. To limit the complexity * of the version 2.0 IBIS_CHK program, it will consider only one * V/I table at a time monotonicity testing. ******************************************************************************* ANALYSIS PATH/DATA THAT LED TO SPECIFICATION: The problems were discovered while the new IBIS_CHK V2.x program was being written. The problems were reported to the IBIS forum at the 10-7-94 meeting by Arpad of Intel. ******************************************************************************* ANY OTHER BACKGROUND INFORMATION: Bird 8.2 address's this issue. From Derrick_Duehren@ccm2.jf.intel.com Fri Oct 28 13:18:14 1994 Return-Path: Received: from ormail.intel.com by vhdl.vhdl.org (4.1/SMI-4.1/BARRNet) id AA01828; Fri, 28 Oct 94 13:18:14 PDT Received: from relay.jf.intel.com by ormail.intel.com with smtp (Smail3.1.28.1 #7) id m0r0xgY-000UeIC; Fri, 28 Oct 94 13:14 PDT Received: from ccm.hf.intel.com by relay.jf.intel.com (Smail3.1.28.1 #2) id m0r0xgY-000tweC; Fri, 28 Oct 94 13:14 PDT Received: by ccm.hf.intel.com (ccmgate 3.0) Fri, 28 Oct 94 13:14:02 PST Date: Fri, 28 Oct 94 13:14:02 PST From: Derrick Duehren Message-Id: <941028131402_1@ccm.hf.intel.com> To: IBIS@vhdl.org Subject: IBIS Disclaimer recommended by Intel Legal Text item: Text_1 Below is Intel Legal Team's recommendation for the IBIS disclaimer. - Derrick DISCLAIMER (to be stored in a file) --------- "The software files or updates are provided by the IBIS Open Forum "as is". The IBIS Open Forum specifically disclaims any warranty, express or implied, including, without limitation, the warranties of merchantability and fitness for a particular purpose or that the software files or updates do not infringe any intellectual property right of a third party. Furthermore, the IBIS Open Forum disclaims any warranty, express or implied, that the software or updates will satisfy user's requirements." DISCLAIMER (to be added to each IBIS file) ---------- [Disclaimer] The IBIS Open Forum disclaims all warranties. See disclaim.ibs in vhdl.org:/pub/IBIS/models for the full disclaimer. From uunet!qdt.com!jonp@uunet.uu.net Fri Oct 28 15:52:05 1994 Return-Path: Received: from relay3.UU.NET by vhdl.vhdl.org (4.1/SMI-4.1/BARRNet) id AA02889; Fri, 28 Oct 94 15:52:05 PDT Received: from uucp7.UU.NET by relay3.UU.NET with SMTP id QQxnpz05029; Fri, 28 Oct 1994 18:46:32 -0400 Received: from qdt.UUCP by uucp7.UU.NET with UUCP/RMAIL ; Fri, 28 Oct 1994 18:46:43 -0400 Received: from hal.qdt.com by qdt.com (4.1/SMI-4.1) id AA01017; Fri, 28 Oct 94 14:46:10 PDT Received: from qdt.com by hal.qdt.com (4.1/SMI-4.1) id AA09315; Fri, 28 Oct 94 14:46:03 PDT Received: from uucp6.UU.NET by relay3.UU.NET with SMTP id QQxnpv28360; Fri, 28 Oct 1994 17:45:52 -0400 Received: from qdt.UUCP by uucp6.UU.NET with UUCP/RMAIL ; Fri, 28 Oct 1994 17:45:52 -0400 Received: from hal.qdt.com by qdt.com (4.1/SMI-4.1) id AA00987; Fri, 28 Oct 94 14:37:15 PDT Received: from f14.qdt.com by hal.qdt.com (4.1/SMI-4.1) id AA09288; Fri, 28 Oct 94 14:37:09 PDT Date: Fri, 28 Oct 94 14:37:09 PDT From: uunet!qdt.com!jonp@uunet.uu.net (Jon Powell) Message-Id: <9410282137.AA09288@hal.qdt.com> Received: by f14.qdt.com (4.1/SMI-4.1) id AA12294; Fri, 28 Oct 94 14:36:22 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 Fri, 28 Oct 94 13:14:02 PST <941028131402_1@ccm.hf.intel.com> Subject: IBIS Disclaimer recommended by Intel Legal We are distributing neither "Software" nor "updates". I think they are simulation models and device characteristic data which the disclaimer could be understood to say "Must be valid" since they weren't mentioned in the disclaimer. jnp From Derrick_Duehren@ccm2.jf.intel.com Fri Oct 28 16:52:10 1994 Return-Path: Received: from ormail.intel.com by vhdl.vhdl.org (4.1/SMI-4.1/BARRNet) id AA03297; Fri, 28 Oct 94 16:52:10 PDT Received: from relay.jf.intel.com by ormail.intel.com with smtp (Smail3.1.28.1 #7) id m0r111k-000UduC; Fri, 28 Oct 94 16:48 PDT Received: from ccm.hf.intel.com by relay.jf.intel.com (Smail3.1.28.1 #2) id m0r111i-000twfC; Fri, 28 Oct 94 16:48 PDT Received: by ccm.hf.intel.com (ccmgate 3.0) Fri, 28 Oct 94 16:48:04 PST Date: Fri, 28 Oct 94 16:48:04 PST From: Derrick Duehren Message-Id: <941028164804_1@ccm.hf.intel.com> To: IBIS@vhdl.org Subject: IBIS Disclaimer recommended by Intel Legal Text item: DISCLAIMER (to be stored in a file) --------- Revised per Jon Powell's comments. I'll run it past Intel Legal again next week. Any other comments? "The simulation models and device characteristic data are provided by the IBIS Open Forum "as is". The IBIS Open Forum specifically disclaims any warranty, express or implied, including, without limitation, the warranties of merchantability and fitness for a particular purpose or that the simulation models and device characteristic data do not infringe any intellectual property right of a third party. Furthermore, the IBIS Open Forum disclaims any warranty, express or implied, that the simulation models and device characteristic data will satisfy user's requirements." - Derrick ================================================================================ We are distributing neither "Software" nor "updates". I think they are simulation models and device characteristic data which the disclaimer could be understood to say "Must be valid" since they weren't mentioned in the disclaimer. jnp 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 Disclaimer recommended by Intel Legal In-Reply-To: Derrick Duehren's message of Fri, 28 Oct 94 13:14:02 PST <941028131 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 AA12294; Fri, 28 Oct 94 14:36:22 PDT Message-Id: <9410282137.AA09288@hal.qdt.com> From: uunet!qdt.com!jonp@uunet.uu.net (Jon Powell) Date: Fri, 28 Oct 94 14:37:09 PDT Received: from f14.qdt.com by hal.qdt.com (4.1/SMI-4.1) id AA09288; Fri, 28 Oct 94 14:37:09 PDT Received: from hal.qdt.com by qdt.com (4.1/SMI-4.1) id AA00987; Fri, 28 Oct 94 14:37:15 PDT Received: from qdt.UUCP by uucp6.UU.NET with UUCP/RMAIL ; Fri, 28 Oct 1994 17:45:52 -0400 Received: from uucp6.UU.NET by relay3.UU.NET with SMTP id QQxnpv28360; Fri, 28 Oct 1994 17:45:52 -0400 Received: from qdt.com by hal.qdt.com (4.1/SMI-4.1) id AA09315; Fri, 28 Oct 94 14:46:03 PDT Received: from hal.qdt.com by qdt.com (4.1/SMI-4.1) id AA01017; Fri, 28 Oct 94 14:46:10 PDT Received: from qdt.UUCP by uucp7.UU.NET with UUCP/RMAIL ; Fri, 28 Oct 1994 18:46:43 -0400 Received: from uucp7.UU.NET by relay3.UU.NET with SMTP id QQxnpz05029; Fri, 28 Oct 1994 18:46:32 -0400 Received: from relay3.UU.NET by vhdl.vhdl.org (4.1/SMI-4.1/BARRNet) id AA02889; Fri, 28 Oct 94 15:52:05 PDT Received: from vhdl.vhdl.org by ormail.intel.com with smtp (Smail3.1.28.1 #7) id m0r10Jj-000UeiC; Fri, 28 Oct 94 16:02 PDT Received: from ormail.intel.com by relay.jf.intel.com with smtp (Smail3.1.28.1 #2) id m0r10Jk-000tweC; Fri, 28 Oct 94 16:02 PDT From icx!bob@uu4.psi.com Sat Oct 29 17:39:39 1994 Return-Path: Received: from uu4.psi.com by vhdl.vhdl.org (4.1/SMI-4.1/BARRNet) id AA14632; Sat, 29 Oct 94 17:39:39 PDT Received: from icx.UUCP by uu4.psi.com (5.65b/4.0.071791-PSI/PSINet) via UUCP; id AA23549 for ; Sat, 29 Oct 94 20:28:04 -0400 Received: by icx.com (/\==/\ Smail3.1.28.1 #28.14) id ; Sat, 29 Oct 94 17:13 PDT Message-Id: Date: Sat, 29 Oct 94 17:13 PDT From: bob@icx.com ( Bob Ross) To: ibis@vhdl.org Subject: BIRD22 - Sub-Parameter Case Sensitivity IBIS Members: BIRD22 eliminates the case-sensitivity requirement for sub-parameters. Bob Ross, Interconnectix, Inc. ***************************************************************************** ***************************************************************************** Buffer Issue Resolution Document (BIRD) BIRD ID#: 22 ISSUE TITLE: Sub-Parameter Case Sensitivity REQUESTOR: Bob Ross, Interconnectix, Inc. DATE SUBMITTED: 29 October 1994 DATE REVISED: DATE ACCEPTED BY IBIS OPEN FORUM: Pending ****************************************************************************** ****************************************************************************** STATEMENT OF THE ISSUE: There appears to be no need to require any of the IBIS subparameters to be case sensitive. ****************************************************************************** STATEMENT OF THE RESOLVED SPECIFICATIONS: Line 1) of the "General syntax rules and guidelines for ASCII IBIS files:" section is modified to add "sub-parameters as shown below by "|*". |============================================================================== | | General syntax rules and guidelines for ASCII IBIS files: | | 1) The content of the files is case sensitive, except for reserved |* words, keywords, sub-parameters (designated by "Sub-Params") |* and sub-parameter definitions. File names must be all lower case. | | 2) The following words are reserved words and must not be used for | any other purposes in the document: | POWER - reserved model name, used with power supply pins, | GND - reserved model name, used with ground pins, | NC - reserved model name, used with no-connect pins, | NA - used where data not available. | | 3) File names used in the file must only have lower case characters to | enhance UNIX compatibility and must conform to DOS rules. (The length of | a file name should not exceed eight plus three characters and it must | not contain special characters which are illegal in DOS). | | 4) The file must have no more than 80 characters per line. | | 5) Anything following the comment character is ignored and considered a | comment on that line. The default "|" (pipe) character can be changed | by the keyword [Comment char] to any other character. The [Comment char] | keyword can be used throughout the file as desired. | | 6) Keywords must be enclosed in square brackets, [], and must start in | column 1 of the line. | | 7) Underscores and spaces are equivalent in keywords. Spaces are not | allowed in sub-parameter names. | | 8) Valid scaling factors are: | T = tera k = kilo n = nano | G = giga m = milli p = pico | M = mega u = micro f = femto | When no scaling factors are specified, the appropriate base units are | assumed. (These are Volts, Amperes, Ohms, Farads, and Henries.) The | parser looks at only one alphabetic character after a numerical entry, | therefore it is enough to use only the prefixes to scale the parameters. | However, for clarity, it is allowed to use full abbreviations for the | units. (e.g., pF, nH, mA, mOhm). In addition, scientific notation IS | allowed (e.g., 1.2345e-12). | | 9) The V/I data tables should use enough data points around sharply curved | areas of the V/I curves to describe the curvature accurately. In linear | regions there is no need to define unnecessary data points. | | 10) Currents are considered positive when their direction is into the | component. | | 11) All temperatures are represented in degrees Celsius. | |============================================================================== ****************************************************************************** ANALYSIS PATH/DATA THAT LED TO SPECIFICATION Sub-parameters include those defined forming column titles (such as L_pin), table rows (such as L_pkg and C_comp), and individual specifications (such as Polarity and Model_type). Also the alpha sub-parameter contents (such as I/O, 3-state and Enable). Version 1.1 requires that these entries are case sensitive, and IBIS_CHK for Version 1.1 flags case violations as errors. Because of context and clear definitions of sub-parameters and their contents, there does not appear to be a need retain the case sensitivity restriction. Furthermore, with a large number of sub-parameters, one tends to make case entry errors since there is no defined rational for case sensitive choices. This change does not effect the ability to parse Version 1.1 compliant IBIS files in Version 2.1 parsers. ****************************************************************************** ANY OTHER BACKGROUND INFORMATION From icx!bob@uu4.psi.com Sat Oct 29 17:39:48 1994 Return-Path: Received: from uu4.psi.com by vhdl.vhdl.org (4.1/SMI-4.1/BARRNet) id AA14637; Sat, 29 Oct 94 17:39:48 PDT Received: from icx.UUCP by uu4.psi.com (5.65b/4.0.071791-PSI/PSINet) via UUCP; id AA23548 for ; Sat, 29 Oct 94 20:28:02 -0400 Received: by icx.com (/\==/\ Smail3.1.28.1 #28.14) id ; Sat, 29 Oct 94 17:11 PDT Message-Id: Date: Sat, 29 Oct 94 17:11 PDT From: bob@icx.com ( Bob Ross) To: ibis@vhdl.org Subject: BIRD21 - Waveform Table Number of Entries IBIS Members: BIRD21 takes care of a specification omission discovered by Paul Munsey. Bob Ross, Interconnectix, Inc. ***************************************************************************** ***************************************************************************** Buffer Issue Resolution Document (BIRD) BIRD ID#: 21 ISSUE TITLE: Waveform Table Minimum Number of Entries REQUESTOR: Bob Ross, Interconnectix, Inc. DATE SUBMITTED: 29 October 1994 DATE REVISED: DATE ACCEPTED BY IBIS OPEN FORUM: Pending ****************************************************************************** ****************************************************************************** STATEMENT OF THE ISSUE: All V/I data tables require at least two entries. The minimum required entries for waveform tables is not explicitly specified. ****************************************************************************** STATEMENT OF THE RESOLVED SPECIFICATIONS: The [Rising Waveform], [Falling Waveform] keyword description contains an additional sentence designated by "|**" to require at least two table entries for each waveform described. Note, the change approved by BIRD19.1 is still shown 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. |** Each table must contain at least two entries. | | 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 Paul Munsey indicated that no minimum number of Waveform table entries were explicitly specified. This addition creates an explicit requirement similar to the documentation of the [Pullup], [Pulldown], [Power Clamp] and [Gnd Clamp] tables. As a minimum, two entries could define the starting and ending points of the total ramp transition and be compatible with the [Ramp] keyword specification. ****************************************************************************** ANY OTHER BACKGROUND INFORMATION From Arpad_Muranyi@ccm.fm.intel.com Mon Oct 31 10:51:24 1994 Return-Path: Received: from ormail.intel.com by vhdl.vhdl.org (4.1/SMI-4.1/BARRNet) id AA04797; Mon, 31 Oct 94 10:51:24 PST Received: from relay.jf.intel.com by ormail.intel.com with smtp (Smail3.1.28.1 #7) id m0r21lH-000UeEC; Mon, 31 Oct 94 10:47 PST Received: from ccm.hf.intel.com by relay.jf.intel.com (Smail3.1.28.1 #2) id m0r21lH-000tx3C; Mon, 31 Oct 94 10:47 PST Received: by ccm.hf.intel.com (ccmgate 3.0) Mon, 31 Oct 94 10:47:19 PST Date: Mon, 31 Oct 94 10:47:19 PST From: Arpad Muranyi Message-Id: <941031104719_2@ccm.hf.intel.com> To: Derrick_Duehren@ccm2.jf.intel.com, ibis@vhdl.org Subject: Re: IBIS Disclaimer recommended by Intel Legal Text item: Text_1 I agree with Jon Powell. Also, I don't think this file should have the extension .ibs. In my mind, the extension .ibs is reserved for IBIS model files which follow very specific syntax rules. This file is a text file, so it should have the extension .txt. If we give it the extension .ibs, people might want to parse it, or other things like that. Other than that, could we speak plain English? I didn't get about half of it... Arpad Below is Intel Legal Team's recommendation for the IBIS disclaimer. - Derrick DISCLAIMER (to be stored in a file) --------- "The software files or updates are provided by the IBIS Open Forum "as is". The IBIS Open Forum specifically disclaims any warranty, express or implied, including, without limitation, the warranties of merchantability and fitness for a particular purpose or that the software files or updates do not infringe any intellectual property right of a third party. Furthermore, the IBIS Open Forum disclaims any warranty, express or implied, that the software or updates will satisfy user's requirements." DISCLAIMER (to be added to each IBIS file) ---------- [Disclaimer] The IBIS Open Forum disclaims all warranties. See disclaim.ibs in vhdl.org:/pub/IBIS/models for the full disclaimer. 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 Disclaimer recommended by Intel Legal To: IBIS@vhdl.org Message-Id: <941028131402_1@ccm.hf.intel.com> From: Derrick Duehren Date: Fri, 28 Oct 94 13:14:02 PST Received: by ccm.hf.intel.com (ccmgate 3.0) Fri, 28 Oct 94 13:14:02 PST Received: from ccm.hf.intel.com by relay.jf.intel.com (Smail3.1.28.1 #2) id m0r0xgY-000tweC; Fri, 28 Oct 94 13:14 PDT Received: from relay.jf.intel.com by ormail.intel.com with smtp (Smail3.1.28.1 #7) id m0r0xgY-000UeIC; Fri, 28 Oct 94 13:14 PDT Received: from ormail.intel.com by vhdl.vhdl.org (4.1/SMI-4.1/BARRNet) id AA01828; Fri, 28 Oct 94 13:18:14 PDT Received: from vhdl.vhdl.org by hermes.intel.com (5.65/10.0i); Fri, 28 Oct 94 13 Received: from hermes.intel.com by relay.jf.intel.com with smtp (Smail3.1.28.1 #2) id m0r0xx0-000twpC; Fri, 28 Oct 94 13:31 PDT From speters@ichips.intel.com Mon Oct 31 17:21:03 1994 Return-Path: Received: from hermes.intel.com by vhdl.vhdl.org (4.1/SMI-4.1/BARRNet) id AA07251; Mon, 31 Oct 94 17:21:03 PST Received: from [134.134.50.200] by hermes.intel.com (5.65/10.0i); Mon, 31 Oct 94 17:16:57 -0800 Received: from xtg801 by ichips.intel.com (5.64+/10.0i); Mon, 31 Oct 94 17:10:51 -0800 Received: from localhost by xtg801.intel.com (4.1/10.0i); Mon, 31 Oct 94 17:16:51 PST Message-Id: <9411010116.AA24327@xtg801.intel.com> To: ibis@vhdl.org Subject: TEST MATRIX Date: Mon, 31 Oct 1994 17:16:49 -0800 From: Stephen Peters Hello Fellow IBISans: As promised during Friday's open forum here is a test matrix of the major functions/features of IBIS 2.x. The spec has been broken into smaller sections, with various tests for each section/keyword. I have filled the matrix out the best I can with the testing I have done. As you finish your testing of a specific section post your results to the reflector (please, refer to the section and test covered) and I will update and post the matrix at regular intervals. Don't be afraid to add more tests to a particlular section -- I don't pretend that the matrix is all inclusive. So far I have been concentrating on the waveform tables and pin mapping. Bob Ross has done some work with the Diff pin keyword and ECL. Please note that this test matrix covers only the "user visable" portion of the parser, at this point testing out the contents of the data structure is left to the the simulator vendors. Have fun...... Regards, Stephen Peters Intel Corp. A TEST MATRIX FOR IBIS VERSION 2.x DATE: 10/31/94 SPECIFICATION TESTED PASS Comments/who tested --------------------------------------+-----+-----------------------------+ Test that the parser only | | | accepts 1.0, 1.1, 2.0, 2.1 as | | | valid arguments to the [IBIS Ver] | yes | Stephen Peters | keyword. | | | | | | --------------------------------------+-----+-----------------------------+ Scaling Factors: | | | | | | Test that the parser recognizes | | | "T", "G" and "f" as valid scaling | ? | No indication either way | factors. | | | | | | Test that the parser does not | | | recognize "t", "g" and "F" as | ? | No indication either way | Valid scaling factors. | | | | | | --------------------------------------+-----+-----------------------------+ Keywords rules: | | | | | | Test that the parser recognizes | | | the [GND clamp] and [PWR clamp] | yes | Stephen Peters | keywords without the underscore. | | | | | | Test that the parser issues an | | | error if a keyword does not begin | yes | Stephen Peters | in column 1. | | | | | | Test case insensitivity of all | | | keywords, reserved words and | NO | Pin mapping keyword does not| sub-parameters | | recognize "power" and "gnd" | | | | --------------------------------------+-----+-----------------------------+ Comments and Notes: | | | | | | Test that the parser does not | | | accept "+" and "-" as valid | yes | Stephen Peters | comment characters. | | | | | | Test that the parser recognizes | yes | Stephen Peters | the [Copyright] keyword. | | | | | | | | | --------------------------------------+-----+-----------------------------+ Component keyword related: | | | | | | Test that the parser issues an | | | error if the [Component] keyword | yes | Stephen Peters | has no component name after it. | | | | | | Test that the parser issues a warning | | | if the component name contains blanks | yes | Stephen Peters | | | | Test the component name length | | | rules: | | | parser accepts name < 40 characters | yes | Stephen Peters | parser accepts name = 40 characters | yes | " | parser fails if name > 40 characters | yes | " | | | | Test that the parser issues an | | | error if the [Manufacture] keyword | yes | Stephen Peters | has no Manufactures name after it. | | | | | | Test the Manufactures name length | | | rules: | | | parser accepts name < 40 characters | yes | Stephen Peters | parser accepts name = 40 characters | yes | Stephen Peters | parser fails if name > 40 characters | yes | Stephen Peters | | | | Test that an .ibs file can contain | | | more than one [Component] keyword | | | and component description. | | | | | | --------------------------------------+-----+-----------------------------+ Pin keyword related: | | | | | | Test that the parser recognizes | yes | Stephen Peters | the [Pin] keyword. | | | | | | Test that the parser issues a | | | error when every model_name does | NO | | not have a corresponding model | | | defined. | | | | | | Test the "3 column or 6 column" | | | rule. | yes | Stephen Peters | | | | Test that the parser issues an error | | | when non-numeric data is in the pin | yes | Stephen Peters | data columns | | | --------------------------------------+-----+-----------------------------+ Package Model related: | | | | | | Test that the parser recognizes | yes | Stephen Peters | the [Package Model] keyword. | | | | | | Test the package model name length | | | rules | | | parser accepts name < 40 characters | no | Name is taken as a DOS file | parser accepts name = 40 characters | no | name and not as argument to | parser fails if name > 40 characters | no | the [Define Package Model] | | | keyword | Verify that the parser issues an | | | error if it cannot find: | | | | | | 1. A [Define Package Model] keyword | | | that has the same argument as the | | | [Package Model] keyword or | | | | | | 2. An external .pkg file that has | | | a [Define Package Model] keyword | | | with has the same argument as the | | | [Package Model] keyword. | | | | | | Test that the parser recognizes all | | | keywords in the package model | | | description: | | | [Define Package Model] | | | [Manufacturer] | | | [OEM] | | | [Description] | | | [Number of Pins] | | | [Pin Numbers] | | | [Model Data] | | | [Resistance Matrix] | | | [Inductance Matrix] | | | [Capacitance Matrix] | | | [Bandwidth] | | | [Row] | | | [End Model Data] | | | [End Package Data] | | | | | | --------------------------------------+-----+-----------------------------+ Pin Mapping keyword related: | | | | | | Test that the parser recognizes | yes | Stephen Peters | the [Pin Mapping] keyword. | | | | | | Test that the parser issues an | | | error if every pin listed in the | NO | | [Pin] keyword does not have an | | | entry in the [Pin Mapping] table | | | | | | Test the "3 column or 5 column" | yes | Stephen Peters | rule. | | | | | | Test that NC is a valid entry | | | in a column. | yes | Stephen Peters | | | | Test that each unique entry label | | | must connect to at least one pin | | | whose model name is POWER or GND | yes | Stephen Peters | | | | --------------------------------------+-----+-----------------------------+ Diff Pin keyword related: | | | | | | Test that the parser recognizes | | | the [Diff Pin] keyword. | | | | | | Test that the parser recognizes | | | the 5 associated sub-parameters | | | | | | Test the "4 column or 6 column" | | | rule. | | | | | | Test that NC is NOT a valid | | | column entry. | | | | | | Test that NA is a valid column | | | entry. | | | | | | --------------------------------------+-----+-----------------------------+ [Model] keyword: | | | | | | Test that the parser recognizes | | | the [Model] keyword. | | | | | | Test that the parser recognizes | | | each Model_type: | | | Input | yes | | Output | yes | | I/O | yes | | 3-state | | | Open_Drain | | | I/O_open_drain | yes | | Open_sink | yes | | I/O_open_sink | | | Open_source | | | I/O_open_source | | | Input_ECL | | | Output_ECL | | | I/O_ECL | | | Terminator | | | | | | Test that the parser issues | | | a warning if an input type model | yes | Stephen Peters | does not have Vinh or Vinl defined. | | | | | | Test that the parser issues an | | | error if the Model_type or C_comp | yes | Stephen Peters | sub-parameters are missing. | | | | | | Test that the parser accepts a | | | [Model] description with only the | | | Model_type and C_comp sub-params | yes | Stephen Peters | defined. | | | | | | Test that the parser allows NA in | | | the min and max columns only of the | yes | Stephen Peters | C_Comp sub-parameter. | | | | | | Test that the parser allows only | | | Non-inverting and Inverting as | yes | Stephen Peters | choices for the Polarity sub-param | | | | | | Test that the parser allows only | | | Active-high and Active-low as | yes | Stephen Peters | choices for the Enable sub-param | | | | | | Test that the parser recognizes | | | the Vmeas, Cref, Rref and Vref | yes | Stephen Peters | sub-parameters. | | | | | | --------------------------------------+-----+-----------------------------+ Temperature keyword related: | | | | | | Test that the parser recognizes | yes | Stephen Peters | the [Temperature Range] keyword | | | | | | --------------------------------------+-----+-----------------------------+ Power supply rail related: | | | | | | Test that the parser recognizes | | | the supply rail keywords | | | [Voltage Range] | yes | Stephen Peters | [Pullup Reference] | " | | [Pulldown Reference] | " | | [POWER Clamp Reference] | " | | [GND Clamp Reference] | " | | | | | Test that the parser issues an | | | error if the [Voltage Range] | | | keyword is absent and all four of | | | the other supply rail keywords are | yes | Stephen Peters | NOT present. | | | | | | --------------------------------------+-----+-----------------------------+ I/V table related: | | | | | | Test that the parser recognizes | | | the [Pullup], [Pulldown], [GND | yes | | Clamp] and [Power Clamp] keywords. | | | | | | Test that the parser issues an | | | error if all three columns are | | | not included | | | | | | Test that NA is accepted in the | | | min and max columns. | | | | | | Test that the parser issues an | | | error if a column contains over | | | 100 points. | | | | | | Test that the parser issues an | | | error if a table contains less | yes | Stephen Peters | than two points. | | | | | | Test that the parser issues a | | | warning if non-monotonic data | | | is found. | | | | | | --------------------------------------+-----+-----------------------------+ Terminator related: | | | | | | Test that the parser recognizes | | | the [Rgnd], [Rpower], [Rac] and | | | [Cac] keywords. | | | | | | Test that the parser issues an | | | error if Model_type is Terminator | | | and at least one of the above | | | keywords is not present. | | | | | | Test that the parser issues an | | | error if all three columns are | | | not included | | | | | | Test that NA is accepted in the | | | min and max columns. | | | | | | --------------------------------------+-----+-----------------------------+ Ramp keyword related: | | | | | | Test that the parser recognizes | | | the [Ramp] keyword and the | yes | Stephen Peters | Dv/dt_r and Dv/dt_f sub-parameters. | | | | | | Test that the parser recognizes | yes | Stephen Peters | the R_load sub-parameter. | | | | | | Test that the R_load sub-parameter | yes | Stephen Peters | is optional. | | | | | | --------------------------------------+-----+-----------------------------+ Waveform Related: | | | | | | Test that the parser recognizes | | | the [Rising Waveform] and [Falling | NO | | Waveform] keywords. | | | | | | Test that the parser recognizes | | | the sub-parameters: | | | R_fixture | NO | | V_fixture | NO | | V_fixture_max | | | V_fixture_min | | | C_fixture | | | L_fixture | | | R_dut | | | L_dut | | | C_dut | | | | | | Test that the parser issues an | | | error if the R_fixture and | | | V_fixture sub-parameters are not | | | present. | | | | | | Test that the parser issues an | | | error if a column contains over | | | 100 points. | | | | | | Test that the parser issues an | | | error if a table contains less | | | than two points. | | | --------------------------------------+-----+-----------------------------+ From schumach@flare.convex.com Tue Nov 1 09:19:25 1994 Return-Path: Received: from convex.convex.com by vhdl.vhdl.org (4.1/SMI-4.1/BARRNet) id AA16572; Tue, 1 Nov 94 09:19:25 PST Received: from flare.convex.com by convex.convex.com (8.6.4.2/1.35) id LAA16538; Tue, 1 Nov 1994 11:08:41 -0600 Received: from localhost by flare.convex.com (8.6.4.2/1.28) id LAA19128; Tue, 1 Nov 1994 11:10:46 -0600 Date: Tue, 1 Nov 1994 11:10:46 -0600 From: schumach@flare.convex.com (Richard A. Schumacher) Message-Id: <199411011710.LAA19128@flare.convex.com> To: ibis@vhdl.org Subject: subscribe schumach@convex.com subscribe schumach@convex.com From gilg@mcc.com Tue Nov 1 10:34:09 1994 Return-Path: Received: from turtle.mcc.com by vhdl.vhdl.org (4.1/SMI-4.1/BARRNet) id AA17378; Tue, 1 Nov 94 10:34:09 PST Received: from outback.mcc.com by turtle.mcc.com (4.1/isd-master_921116_15:19) id AA12684; Tue, 1 Nov 94 12:30:04 CST Received: from cc:Mail by outback.mcc.com id AA783721754; Tue, 01 Nov 94 12:28:44 CST Date: Tue, 01 Nov 94 12:28:44 CST From: "Gilg" Encoding: 1 Text Message-Id: <9410017837.AA783721754@outback.mcc.com> To: ibis@vhdl.org Subject: I/O models I'm interested in information about ibis I/O models for ICs. From Derrick_Duehren@ccm2.jf.intel.com Tue Nov 1 17:59:20 1994 Return-Path: Received: from ormail.intel.com by vhdl.vhdl.org (4.1/SMI-4.1/BARRNet) id AA22318; Tue, 1 Nov 94 17:59:20 PST Received: from relay.jf.intel.com by ormail.intel.com with smtp (Smail3.1.28.1 #7) id m0r2Uur-000UdtC; Tue, 1 Nov 94 17:55 PST Received: from ccm.hf.intel.com by relay.jf.intel.com (Smail3.1.28.1 #2) id m0r2Uur-000twdC; Tue, 1 Nov 94 17:55 PST Received: by ccm.hf.intel.com (ccmgate 3.0) Tue, 1 Nov 94 17:55:08 PST Date: Tue, 1 Nov 94 17:55:08 PST From: Derrick Duehren Message-Id: <941101175508_1@ccm.hf.intel.com> To: IBIS@vhdl.org Subject: IBIS: Date for December face-to-face Text item: Text_1 IBISians, When would you like to meet for our face-to-face General Session? Please respond to me with your preferences. Please label the days: A (1st choice) B (second) C (third) X (no can do) You can have multiples of each type (i.e., more than one first choice). I will matrix them to find the appropriate day. Your choices are: Mon, 12/5 Tues, 12/6 Wed, 12/7 Thur, 12/8 Fri, 12/9 Mon, 12/12 Tues, 12/13 Wed, 12/14 Thur, 12/15 Fri, 12/16 - Derrick Duehren Intel Corp. From 73053.721@compuserve.com Tue Nov 1 22:54:53 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 AA24140; Tue, 1 Nov 94 22:54:53 PST Received: from localhost by dub-img-2.compuserve.com (8.6.4/5.940406sam) id BAA13846; Wed, 2 Nov 1994 01:50:49 -0500 Date: 02 Nov 94 01:48:36 EST From: Paul Munsey <73053.721@compuserve.com> To: IBIS Reflector Cc: Ron Neville <75123.3477@compuserve.com> Subject: Beta 2 and more Message-Id: <941102064835_73053.721_GHB35-1@CompuServe.COM> Ron and I have discusses the timing for sending out a second beta, and although I verbalized the ability to do this by the end of this week (11/4) it will work better for us to shoot for 11/8. I appologize for the delay, but the extra weekend will benefit our effort. It has also been discovered through discussion with Ron, Bob Ross, and Stephen Peters that the referencing of package models in external .pkg files does not work correctly. In addition, here's some IBIS spec item's that may be worth mentioning: * No 'I' sign error checking info is mentioned or defined in the spec * Model info on 3-state, polarity, and enable have their casing inconsistent with the V1.1 spec. I understand that a BIRD may soon be passed which will allow ignoring of casing, so this may be a mute point. * No minimum number of waveform data points is required Last but not least, the last meeting generated the request for some additional enhancements to be added to the parser, also known as "feature creep". Ron and I would like to hold off on these for now. At times these may be simple, or appear so, but we would first like to make sure we accomplish what we promised. And even though the task may be simple it requires us to revisit completed code and rework our test suites. Once we feel confident that all the requirements are met we will be more able to discuss additional enhancements. Paul Munsey From Will_Hobbs@ccm2.jf.intel.com Wed Nov 2 18:28:16 1994 Return-Path: Received: from ormail.intel.com by vhdl.vhdl.org (4.1/SMI-4.1/BARRNet) id AA07252; Wed, 2 Nov 94 18:28:16 PST Received: from relay.jf.intel.com by ormail.intel.com with smtp (Smail3.1.28.1 #7) id m0r2rqO-000UdOC; Wed, 2 Nov 94 18:24 PST Received: from ccm.jf.intel.com by relay.jf.intel.com (Smail3.1.28.1 #2) id m0r2rqN-000twdC; Wed, 2 Nov 94 18:24 PST Received: by ccm.jf.intel.com (ccmgate 3.0) Wed, 2 Nov 94 18:24:03 PST Date: Wed, 2 Nov 94 18:24:03 PST From: Will Hobbs Message-Id: <941102182403_1@ccm.jf.intel.com> To: Derrick_Duehren@ccm2.jf.intel.com, IBIS@vhdl.org Subject: Re: IBIS: Date for December face-to-face Text item: Text_1 Derrick, I've listed my preferences next to the dates. Will IBISians, When would you like to meet for our face-to-face General Session? Please respond to me with your preferences. Please label the days: A (1st choice) B (second) C (third) X (no can do) You can have multiples of each type (i.e., more than one first choice). I will matrix them to find the appropriate day. Your choices are: Mon, 12/5 D Tues, 12/6 OK Wed, 12/7 X Thur, 12/8 OK Fri, 12/9 A Mon, 12/12 B Tues, 12/13 OK Wed, 12/14 X Thur, 12/15 OK Fri, 12/16 C - Derrick Duehren 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: Date for December face-to-face To: IBIS@vhdl.org Message-Id: <941101175508_1@ccm.hf.intel.com> From: Derrick Duehren Date: Tue, 1 Nov 94 17:55:08 PST Received: by ccm.hf.intel.com (ccmgate 3.0) Tue, 1 Nov 94 17:55:08 PST Received: from ccm.hf.intel.com by relay.jf.intel.com (Smail3.1.28.1 #2) id m0r2Uur-000twdC; Tue, 1 Nov 94 17:55 PST Received: from relay.jf.intel.com by ormail.intel.com with smtp (Smail3.1.28.1 #7) id m0r2Uur-000UdtC; Tue, 1 Nov 94 17:55 PST Received: from ormail.intel.com by vhdl.vhdl.org (4.1/SMI-4.1/BARRNet) id AA22318; Tue, 1 Nov 94 17:59:20 PST Received: from vhdl.vhdl.org by hermes.intel.com (5.65/10.0i); Tue, 1 Nov 94 18: Received: from hermes by ichips.intel.com (5.64+/10.0i); Tue, 1 Nov 94 17:58:55 Received: from ichips.intel.com by relay.jf.intel.com with smtp (Smail3.1.28.1 #2) id m0r2V4f-000twdC; Tue, 1 Nov 94 18:05 PST From icx!bob@uu4.psi.com Thu Nov 3 19:39:43 1994 Return-Path: Received: from uu4.psi.com by vhdl.vhdl.org (4.1/SMI-4.1/BARRNet) id AA22888; Thu, 3 Nov 94 19:39:43 PST Received: from icx.UUCP by uu4.psi.com (5.65b/4.0.071791-PSI/PSINet) via UUCP; id AA07119 for ; Thu, 3 Nov 94 22:25:34 -0500 Received: by icx.com (/\==/\ Smail3.1.28.1 #28.14) id ; Thu, 3 Nov 94 19:04 PST Message-Id: Date: Thu, 3 Nov 94 19:04 PST From: bob@icx.com ( Bob Ross) To: ibis@vhdl.org Subject: BNF 2.1 Comment Steffen Rochel and Ibis Committee: In general, I agree with Will's comment that the Specification should not be updated to comply with a more easily formulated BNF for compatibility reasons. We are stuck with some of the Version 1.1 flexable placement of keywords. Therefore, without really extensive listing of alternatives, the BNF will never fully capture the IBIS standard. Also, there are some placement restrictions and number of usage limits that may not be fully documented in IBIS Version 1.1 and IBIS Version 2.0, but show up with IBIS_CHK. I do not remember all the cases, but you may not use [Date] more than once, as an example of an unspecified limitation. The BNF appears to accurately capture the syntax of each of the keywords and most other aspects of IBIS 2.1. It is not perfect, but should serve as a good auxillary document. Very good parsers can be derived from it. In practice, many of us will choose not produce a parser that is as rigid as the specification. For example, we will correctly parse *.ibs files that contain strings of any length, not just those with the IBIS mandated length limits. So our model names can exceed 20 characters and the pin numbers can exceed 5 characters. We have added some additional non-standard capablities that are applicable to our product. Bob Ross Interconnectix, Inc. From schmahl@slszwat Fri Nov 4 09:13:19 1994 Return-Path: Received: from slsa02t.stgl.netd.alcatel.de by vhdl.vhdl.org (4.1/SMI-4.1/BARRNet) id AA02001; Fri, 4 Nov 94 09:13:19 PST Received: from slssn1t.stgl.sel.alcatel.de by slsa02t.stgl.netd.alcatel.de with SMTP (PP) id <29232-0@slsa02t.stgl.netd.alcatel.de>; Fri, 4 Nov 1994 18:09:32 +0100 Received: from slszwat.stgl.sel.alcatel.de by slssn1t.stgl.sel.alcatel.de (4.1/SMI-4.1-DNI-7.0.1) id AA21411; Fri, 4 Nov 94 18:09:53 +0100 Received: from slszwbt.vs_ehc6 by slszwat.stgl.sel.alcatel.de (4.1/SMI-4.1-DNI) id AA04108; Fri, 4 Nov 94 18:13:02 +0100 Received: by slszwbt.vs_ehc6 (4.1/SMI-4.1-DNI-7.0.1) id AA01813; Fri, 4 Nov 94 18:13:03 +0100 Date: Fri, 4 Nov 1994 18:10:44 +0100 (MET) From: Gerhard Schmahl Subject: To: IBIS Emailer Message-Id: Mime-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII unsubscribe GSchmahl@stgl.sel.alcatel.de Regards, Gerhard Schmahl ======================================================================= Gerhard Schmahl Phone: (+49) 711 821 - 45526 Alcatel SEL AG Fax: (+49) 711 821 - 45551 Dept. VS/EHC6 Internet: GSchmahl@stgl.sel.alcatel.de Lorenzstrasse 10 70435 Stuttgart, Germany =========================== End of Email ============================== From kurobe@asic.mtv.nec.com Fri Nov 4 09:42:42 1994 Return-Path: Received: from archimedes.inoc.sj.nec.com (archimedes.inoc.sj.nec.com) by vhdl.vhdl.org (4.1/SMI-4.1/BARRNet) id AA02238; Fri, 4 Nov 94 09:42:42 PST Received: by inoc.sj.nec.com (8.6.8.1/YDL1.7-930126.17) id JAA06380(archimedes.inoc.sj.nec.com ); Fri, 4 Nov 1994 09:39:44 -0800 Received: by sj.nec.com (8.6.8.1/YDL1.7-940623.1) id JAA08288(netkeeper.sj.nec.com ); Fri, 4 Nov 1994 09:38:26 -0800 Received: by asic.mtv.nec.com (4.1/) id AA07143(elmailer.asic.mtv.nec.com); Fri, 4 Nov 94 09:46:38 PST Received: from mtvipc6.asic.mtv.nec.com by mtv205.asic.mtv.nec.com (4.1/SMI-4.1) id AA27229; Fri, 4 Nov 94 09:42:19 PST Date: Fri, 4 Nov 94 09:42:19 PST From: kurobe@asic.mtv.nec.com (Tsuneo Kurobe) Message-Id: <9411041742.AA27229@mtv205.asic.mtv.nec.com> To: ibis@vhdl.org Cc: kurobe@asic.mtv.nec.com unsubscribe kurobe@asic.mtv.nec.com Regards, Tsuneo Kurobe From Rod_Strange@ccm2.hf.intel.com Fri Nov 4 10:44:29 1994 Return-Path: Received: from ormail.intel.com by vhdl.vhdl.org (4.1/SMI-4.1/BARRNet) id AA02773; Fri, 4 Nov 94 10:44:29 PST Received: from relay.jf.intel.com by ormail.intel.com with smtp (Smail3.1.28.1 #7) id m0r3TYa-000UgCC; Fri, 4 Nov 94 10:40 PST Received: from ccm.hf.intel.com by relay.jf.intel.com (Smail3.1.28.1 #2) id m0r3TYY-000tweC; Fri, 4 Nov 94 10:40 PST Received: by ccm.hf.intel.com (ccmgate 3.0) Fri, 4 Nov 94 10:40:09 PST Date: Fri, 4 Nov 94 10:40:09 PST From: Rod Strange Message-Id: <941104104009_3@ccm.hf.intel.com> To: ibis@vhdl.org Subject: Re: Text item: unsubscribe stramond@teleport.com Text item: External Message Header The following mail header is for administrative use and may be ignored unless there are problems. ***IF THERE ARE PROBLEMS SAVE THESE HEADERS***. Content-Type: TEXT/PLAIN; charset=US-ASCII Mime-Version: 1.0 Message-Id: To: IBIS Emailer From: Gerhard Schmahl Date: Fri, 4 Nov 1994 18:10:44 +0100 (MET) Received: by slszwbt.vs_ehc6 (4.1/SMI-4.1-DNI-7.0.1) id AA01813; Fri, 4 Nov 94 18:13:03 +0100 Received: from slszwbt.vs_ehc6 by slszwat.stgl.sel.alcatel.de (4.1/SMI-4.1-DNI) id AA04108; Fri, 4 Nov 94 18:13:02 +0100 Received: from slszwat.stgl.sel.alcatel.de by slssn1t.stgl.sel.alcatel.de (4.1/SMI-4.1-DNI-7.0.1) id AA21411; Fri, 4 Nov 94 18:09:53 +0100 Received: from slssn1t.stgl.sel.alcatel.de by slsa02t.stgl.netd.alcatel.de with SMTP (PP) id <29232-0@slsa02t.stgl.netd.alcatel.de>; Fri, 4 Nov 1994 18:09:32 +0100 Received: from slsa02t.stgl.netd.alcatel.de by vhdl.vhdl.org (4.1/SMI-4.1/BARRNe id AA02001; Fri, 4 Nov 94 09:13:19 PST Received: from vhdl.vhdl.org (vhdl.vhdl.org [198.31.14.3]) by teleport.com (8.6. Received: from desiree.teleport.com by hermes.intel.com (5.65/10.0i); Fri, 4 Nov Received: from hermes.intel.com by relay.jf.intel.com with smtp (Smail3.1.28.1 #2) id m0r3SdA-000twfC; Fri, 4 Nov 94 09:40 PST