From owner-ibis Sun Mar 2 13:18:20 1997 Received: from icx.com (root@fw.icx.com [205.238.6.33]) by vhdl.vhdl.org (8.8.5/8.8.3) with SMTP id NAA12999 for ; Sun, 2 Mar 1997 13:18:19 -0800 (PST) Received: by icx.com (/\oo/\ Smail3.1.29.1 #29.2) id ; Sun, 2 Mar 97 13:16 PST Received: by icx.com (/\==/\ Smail3.1.28.1 #28.14) id ; Sun, 2 Mar 97 13:16 PST Received: by icx.com (/\==/\ Smail3.1.28.1 #28.14) id ; Sun, 2 Mar 97 13:18 PST Message-Id: Date: Sun, 2 Mar 97 13:18 PST From: bob@icx.com ( Bob Ross) To: ibis@vhdl.org Subject: IBIS AGENDA March 7, 1997 IBIS Open Forum Meeting Agenda for 3/7/97 Bridge Number Reservation # Passcode (916) 356-9200 3-87786 1568848 All meetings are 8:00 AM to 9:55 AM Pacific Time. When you call into the meeting, ask for the IBIS Open Forum hosted by Will Hobbs and give the Reservation Number and Passcode. 8:00 Check-In, Intros, Announcements Ross - Intros of New IBIS Participants, Meeting Quorum Ross - Membership Update and Treasurers Report Rusher - Review of Previous Meeting's Minutes (and ARs) Ross - Miscellany/Announcements All - Press & Web Page Updates Huq, All - New Models Available, Library Update Powell, All - Opens for New Issues All 8:25 Administrative and Project Discussions DAC97 IBIS Meeting Planning Rusher International Progress/Developments Rusher/Ross Purchase National IBIS Article Reprints Huq - html conversion Roster Update Huq Parser Status Rokusek Cookbook Rokusek New Administrative Issues All 8:50 Technical Discussion BIRD41.1 - MODELING SERIES SWITCHABLE DEVICES Ross Package Committee Report Peters BIRD36.1 - ELECTRICAL DESCRIPTIONS OF BOARDS Peters Package Committee Report Peters Switched Terminators Muranyi BUG8 - Pin Name Resolution Ross New Technical Issues All 9:50 Wrap Up and Next Meetings Plans Ross 9:55 Sign Off From owner-ibis Mon Mar 3 07:50:42 1997 Received: from icx.com (root@fw.icx.com [205.238.6.33]) by vhdl.vhdl.org (8.8.5/8.8.3) with SMTP id HAA28333 for ; Mon, 3 Mar 1997 07:50:40 -0800 (PST) Received: by icx.com (/\oo/\ Smail3.1.29.1 #29.2) id ; Mon, 3 Mar 97 07:47 PST Received: by icx.com (/\==/\ Smail3.1.28.1 #28.14) id ; Mon, 3 Mar 97 07:47 PST Received: by icx.com (/\==/\ Smail3.1.28.1 #28.14) id ; Mon, 3 Mar 97 07:49 PST Message-Id: Date: Mon, 3 Mar 97 07:49 PST From: bob@icx.com ( Bob Ross) To: ibis@vhdl.org Subject: BIRD36.1 Comments Stephen: As discussed in the Packaging Subcommittee meeting on Friday, February 28, 1997, I wanted to submit some comments on BIRD36.1. Below are some editorial and technical comments that reflect some revised thinking. 1. Editorial: Under "Contents:" Capitalize [File Name], [File Rev], and [Comment Char]. 2. Editorial: Under [Pin List], Description:, change to read "Tells the parser the pin names of the user accessible pins." 3. Editorial: Under [Path Description], should "who's" be "whose"? 4. Editorial: Under [Path Description], Usage Rules:, change ".. a sections electrical properties .." to ".. electrical properties of a section ..". 5. Editorial: Under [Path Description], SECTION DESCRIPTION SUBPARAMETERS, Len, I prefer to use "interpreted" instead of "treated". Also, see 10 below. 6. Editorial: Under [Path Description], SECTION DESCRIPTION SUBPARAMETERS, L, change "3.0nH" to "3.0 nH" and "1.5nH" to "1.5 nH". 7. Technical: Under [Path Description], SECTION DESCRIPTION SUBPARAMETERS, Node, I prefer to have verbiage stating that the Node references the pin of a component or the pin of an electrical board description contained in a .ibs or .ebd file. See 12 below. 8. Technical: Under [Path Description], SECTION DESCRIPTION SUBPARAMETERS, Pin, after some thought, I believe it is possible to state that each signal pin (other than POWER, GND, or NC) must be named once and only once within all of the [Path Description]s of the [Begin Board Description] keyword. The POWER, GND and NC pins may optionally be named once. This rule will make it easier for the file checking utility to detect description errors. Furthermore, it might be noted that the pin names do not have to occur in the same order as they appear in the [Pin List] table. 9. Editorial: Under [Path Description], Using The Subparameters to Describe Paths:, the last sentence should delete the "(/)" reference since it is already defined in the paragraph. 10. Editorial: Under [Path Description], Using The Subparameters to Describe Paths:, last sentence of second paragraph, I would prefer using "interpreted" for "treated" as in 5. above. 11. Editorial: Under [Path Description], A DESCRIPTION USING THE FORK AND ENDFORK SUBPARAMETERS, Add n and spacing changes and slash to change the line to "Len = 1.0 L=1.0n C=2.0p /" Also three lines below, change "l = 6.0n" to "L=6.0n". 12. Technical: Under [Reference Designator Map], Add text and change the example to add an additional column for component name or board description name since both the .ibs and .ebd files can contain multiple occurrences of components or board descriptions. The new column may follow the part reference column. Also, I have a problem with allowing actual path descriptions in a STANDARDIZED file description. All of the .ibs and .ebd files should be contained in the same directory - at least as a DEFAULT. Simulator specific editors can work with allowing name substitutions and more complicated path descriptions. One problem is that a specific 80286.ibs component may come from different vendors and carry different component names and be stored in different directories. The difference between traditional DOS and UNIX directory structure notation makes this an operating system-specific, simulator specific-issue and installation-specific issue. Furthermore, the path descriptions along with the other columns could, in practice, cause columns to exceed the 80 characterter width limit. Simulators may allow such exceptions including arbitrary path description lengths, but for standardization and transportability of files, this should not be allowed. Forcing the specification of a specific (default) component at this time will eliminate some future practical problems that many components come in different package configurations with different pin numbers (e.g., PLCC and PGA). A generic specification "80286.ibs" is to ambiguous for future needs and will just lead to application errors. Question: Can there be multiple occurrences of the same reference designator (e.g., u23 for 80286.ibs and u23 for abc286.ibs)? The first occurrence could be the default, but the additional occurrences may be available as selection options. Finally, the example shows u26, R10K. That should be a .ibs file. Overall, you did a nice job in capturing into BIRD36.1 a very workable format for describing boards. I look forward to voting on this as soon as some to the issues above are resolved. Bob Ross Interconnectix From owner-ibis Fri Mar 7 12:21:52 1997 Received: from ormail.intel.com (ormail.intel.com [134.134.248.3]) by vhdl.vhdl.org (8.8.5/8.8.3) with ESMTP id MAA07968 for ; Fri, 7 Mar 1997 12:21:51 -0800 (PST) Received: from ichips.intel.com (ichips.intel.com [134.134.50.200]) by ormail.intel.com (8.8.4/8.8.4) with ESMTP id MAA23597 for ; Fri, 7 Mar 1997 12:19:58 -0800 (PST) Received: from ichips.intel.com by ichips.intel.com (8.7.4/jIII) id MAA21109; Fri, 7 Mar 1997 12:12:29 -0800 (PST) Message-Id: <199703072012.MAA21109@ichips.intel.com> To: ibis@vhdl.org Subject: Bird 36.2 Date: Fri, 07 Mar 1997 12:20:07 -0800 From: Stephen Peters Hello fellow IBISains: Per our discussion at the meeting today, here is Bird36.2. This version includes Bob Ross's comments. Enjoy.... Regards, Stephen Peters Intel Corp. ------------------ cut here ----------------------------------------- Buffer Issue Resolution Document (BIRD) BIRD ID#: 36.2 ISSUE TITLE: Electric Descriptions of Boards REQUESTER: Stephen Peters, Hank Herrmann DATE SUBMITTED: June 23, 1996 DATE ACCEPTED BY IBIS OPEN FORUM: Pending ****************************************************************************** ****************************************************************************** STATEMENT OF THE ISSUE: There is a need to describe SIMM modules and related type components that consist of one or more ICs mounted on a PCB board that connects them to a system thru a set of pins. The following BIRD proposes a new type of file called .ebd (Electrical Board Description) that addresses this need. This proposal does not encompass an electrical description of connectors and other interconnect devices. ****************************************************************************** STATEMENT OF THE RESOLVED SPECIFICATIONS: The following text is placed in the specification after the .pkg file description and before the [End] keyword description. ==================== ELECTRICAL BOARD DESCRIPTION ==================== An Board Level Component is defined as a part that connects one or more IC packages to another part or board thru a set of user visible pins. For example, a SIMM module is an board level component in that it connects several DRAM packages to a PCB thru an edge connector. To provide a simple electrical description of the connection between the pins of the board level component and the IC packages, an electrical board description file (a .ebd file) is defined. A fundamental assumption regarding the electrical board description is that the inductance and capacitance parameters listed in the file are derived with respect to well defined reference plane(s) within the board. Also, this current description does not allow one to describe electrical (inductive or capacitive) coupling between paths. It is recommended that if coupling is an issue than an electrical description be extracted from the boards physical parameters. What is, and is not, included in an Electrical Board Description is defined by its boundaries. For the definition of the boundaries, see the Description section under the [Path Description] Keyword. Usage Rules: A .ebd file is intended to be a stand alone file, not associated with any .ibs file. Board level component descriptions are stored in a file whose name looks like .ebd, where must conform to the naming rules given in the general syntax section of this specification. The .ebd extension is mandatory. Contents: A .ebd file is structured similar to a standard IBIS file. It must contain the following keywords, as defined in the IBIS specification: [IBIS Ver], [File Name], [File Rev], and [End]. It may also contain the following optional keywords: [Comment Char], [Date], [Source], [Notes], [Disclaimer] and [Copyright]. The actual board level component description is contained between the keywords [Begin Board Description] and [End Board Description], and includes the keywords listed below. [Begin Board Description] [Manufacturer] [Number of Pins] [Pin List] [Path Description] [Reference Designator Map] [End Board Description] More than one [Begin Board Description]/[End Board Description] keyword pair is allowed in a .ebd file. |============================================================================= | Keyword: [Begin Board Description] | Required: Yes |Description: Marks the beginning of an Electrical Board Description. |Usage Rules: The keyword is followed by the name of the board level | component. If the .ebd file contains more than one [Begin | Board Description] keyword, then each name must be unique. | The length of the component name must not exceed 40 characters | in length, and blank characters are allowed. For every | [Begin Board Description] keyword there must be a | matching [End Board Description] keyword. |----------------------------------------------------------------------------- [Begin Board Description] 16Meg X 8 Simm Module | |============================================================================= | Keyword: [Manufacturer] | Required: Yes |Description: Declares the manufacturer of the part(s) that use this .ebd | file. |Usage Rules: Following the keyword is the manufacturers name. It must not | exceed 40 characters, and can include blank characters. Each | manufacturer must use a consistent name in all .ebd files. |----------------------------------------------------------------------------- [Manufacturer] Quality SIMM Corp. | |============================================================================= | Keyword: [Number of Pins] | Required: Yes |Description: Tells the parser the number of pins to expect. Pins are any | externally accessible electrical connection to the part. |Usage Rules: The field must be a positive decimal integer. | Note: The simulator must not limit the Number of Pins to any | value less than 1,000. |----------------------------------------------------------------------------- [Number of Pins] 128 | |============================================================================= | Keyword: [Pin List] | Required: Yes |Description: Tells the parser the pin names of the user accessible | pins. It also informs the parser which pins are connected to | power and ground. |Sub-params: pin_name signal_name |Usage Rules: Following the [Pin List] keyword are two columns. The first | column lists the pin name while the second lists the data book | name of the signal connected to that pin. There must be as many | pin_name/signal_name rows as there are pins given by the | preceding [Number of Pins] keyword. Pin names must be the | alphanumeric external pin names of the part. The pin | names cannot exceed eight characters in length. Any pin | associated with a signal name that begins with "GND" or | "POWER" will be interpreted as connecting to the boards ground | or power plane. In addition, NC is a legal signal name and | indicates that the Pin is a 'no connect'. | |----------------------------------------------------------------------------- | A SIMM BOARD EXAMPLE | [Pin List] pin_name signal_name A1 GND A2 data1 A3 data2 A4 POWER5 | this pin connects to 5v A5 NC | a no connect pin | . | . A22 POWER3.3 | this pin connects to 3.3v B1 casa | . | . |etc. | |============================================================================ | Keyword: [Path Description] | Required: Yes |Description: This keyword allows the user to describe the connection | between the user accessible pins of a part and the pins of | the ICs mounted on that part. Each pin to node connection is | divided into one or more cascaded "sections", where each | section is described in terms of it's L/R/C per unit length. | The Fork and Endfork subparameters allow the path to branch | to multiple nodes, or another pin. A path description is | required for each pin whose signal name is not "GND", "POWER" | or "NC". | | BOARD DESCRIPTION AND IC BOUNDARIES: | In any system, each part interfaces with another part at some | boundary. Every part model must contain the components | necessary to represent the behavior of the part being modeled | within its boundaries. The boundary definition depends upon | the parts being represented by the model. | | For CARD EDGE CONNECTIONS such as a SIMM or a PC Daughter | Card plugged into a SIMM Socket or Edge Connector, the | boundary should be at the end of the board card edge pads as | they emerge from the connector. | | For any THROUGH-HOLE MOUNTED PART, the boundary will be at | the surface of the board on which the part is mounted. | | SURFACE MOUNTED PART models end at the outboard end of their | recommended surface mount pads. | | If the board level component contains an UNMATED CONNECTOR, | the unmated connector will be described in a separate file, | with it's boundaries being as described above for the | through-hole or surface mounted part. | | Sub-params: Len, L, R, C, Fork, Endfork, Pin, Node |Usage Rules: Each individual connection path (user pin to node(s)) | description begins with the | [Path Description] keyword and a path name, followed by the | subparameters used to describe the path topology and the | electrical characteristics of each section of the path. The | path name must not exceed 40 characters, blanks are not allowed, | and each occurrence of the [Path Description] keyword must be | followed by a unique path name. Every signal pin (pins other | than POWER, GND or NC) must appear in one and only one path | description per [Begin Board Description]/[End Board | Description] pair. Pin names do not have to appear in the | same order as listed in the [Pin List] table. The individual | subparameters are broken up into those that describe the | electrical properties of a section, and those that describe | the topology of a path. | | SECTION DESCRIPTION SUBPARAMETERS: | The Len, L, R, and C subparameters specify the length, the | series inductance and resistance and the capacitance to ground | of each section in a path description. | Len The physical length of a section. Lengths are given | in terms of arbitrary 'units'. Any non-zero length | requires that the parameters that follow must be | interpreted as distributed elements by the simulator. | L The series inductance of a section, in terms of | 'inductance/unit length'. For example, if the total | inductance of a section is 3.0 nH and the length of the | section is 2 'units', the inductance would be listed | as L = 1.5 nH (i.e. 3.0 / 2). | C The capacitance to ground of a section, in terms of | capacitance per unit length. | R The series DC (ohmic) resistance of a section, in | terms of ohms per unit length. | | TOPOLOGY DESCRIPTION SUBPARAMETERS: | The Fork and Endfork subparameters denote branches from the | main pin-to-node or pin-to-pin connection path. The Node | subparameter is used to reference the pin of a component | or board as defined in a .ibs or .edb file. The Pin | subparameter is used to indicate the point at which a path | connects to a user visible pin. | Fork This subparameter indicates that the sections | following (up to the Endfork subparameter) are part | of a branch off of the main connection path. This | subparameter has no arguments. | Endfork This subparameter indicates the end point of a | branch. For every Fork subparameter there must be a | corresponding Endfork subparameter. As with the Fork | subparameter, the Endfork subparameter has no arguments. | Node reference_designator.pin | This subparameter is used when the connection path | connects to a pin of another, externally defined part. | The arguments of the Node subparameter indicate the pin | and reference designator of the external component. The | pin and reference designator portions of the argument are | separated by a period ("."). The reference designator is | mapped to an external component description (another .ebd | file or .ibs file) by the [Reference Designator Map] | Keyword. Note that a Node MUST reference a model of | a passive or active component. A Node is not an | arbitrary connection point between two elements or | paths. | Pin This subparameter is used to mark the point at which | a path description connects to a user accessible pin. | Every path description must contain at least one | occurrence of the Pin subparameter. It may also contain | the reserved word NC. The value of the Pin subparameter | must be one of the pin names listed in the [Pin List] | section. | | Using The Subparameters to Describe Paths: | A section description begins with the Len subparameter and | ends with the slash (/) character. The value of the Len, L, | R and C subparameters and the subparameter itself are separated | by an equals sign (=); whitespace around the equals sign is | optional. The Fork, Endfork, Node and Pin subparameters are | placed between section descriptions (i.e. between the concluding | slash of one section and the 'Len' parameters that starts | another). The arguments of the Pin and Node subparameter are | separated by white space. | | Specifying a Len or L/R/C value of zero is allowed. If | Len = 0 is specified, then the L/R/C values are the total | for that section. If a non-zero length is specified, then | the total L/R/C for a section is calculated by multiplying | the value of the Len subparameter by the value of the L, | R or C subparameter. However, as noted below, if a non- | zero length is specified, that section MUST be interpreted as | distributed elements. | | Legal Subparameter Combinations for Section Descriptions: | | A) Len, and one or more of the L, R and C subparameters. If | the Len subparameter is given as zero, then the L/R/C sub- | parameters represent lumped elements. If the Len subparameter | is non-zero, then the L/R/C subparameters represent distributed | elements and both L and C must be specified, R is optional. | | B) The first subparameter following the [Path Description] | keyword must be 'Pin', followed by one or more section | descriptions. The path description can terminate in a node, | another pin or the reserved word, NC. | |--------------------------------------------------------------------------- | | | AN EXAMPLE PATH FOR A SIMM MODULE | [Path Description] CAS_2 Pin J25 Len = 0.5 L=8.35n C=3.34p R=0.01 / Node u21.15 Len = 0.5 L=8.35n C=3.34p R=0.01 / Node u22.15 Len = 0.5 L=8.35n C=3.34p R=0.01 / Node u23.15 | | A DESCRIPTION USING THE FORK AND ENDFORK SUBPARAMETERS | [Path Description] PassThru1 Pin B5 Len = 0 L=2.0n / Len = 2.1 L=6.0n C=2.0p / Fork Len = 1.0 L = 1.0n C= 2.0p / Node u23.15 Endfork Len = 1.0 L = 6.0n C=2.0p / Pin A5 | |============================================================================= | Keyword: [Reference Designator Map] | Required: Yes, if any of the path descriptions use the Node subparameter. |Description: Maps a reference designator to a component or electrical | board description contained in an .ibs or .edb file. |Usage Rules: The [Reference Designator Map] keyword must be followed by a | list of all of the reference designators called out by the Node | subparameters used in the various path descriptions. Each | reference designator is followed by the name of the .ibs or | .ebd file containing the electrical description of the | component or board, then the name of the component itself as | given by the .ibs or .ebd file's [Component] or [Begin Board | Description] keyword respectively. The reference designator, | file name and component name terms are separated by whitespace. | By default the .ibs or .ebd files are assumed to exist in the | same directory as the calling .edb file. It is legal for a | reference designator to point to a component that is | contained in the calling .ebd file. |----------------------------------------------------------------------------- [Reference Designator Map] | | EXTERNAL PART REFERENCES | |Ref Des File name Component name u23 pp100.ibs Pentium(R)__Pro_Processor u24 SIMM.ebd 16Meg X 36 SIMM Module u25 LS244.ibs National 74LS244a u26 R10K.ibs My_10K_Pullup | |============================================================================= | Keyword: [End Electrical Description] | Required: Yes |Description: Marks the end of an Electrical Interconnect Description. |Usage Rules: This keyword must come at the end of each complete electrical | interconnect model description. | | Optionally, a comment may be added after the [End Electrical | Description] keyword to clarify which board model has | ended. |----------------------------------------------------------------------------- [End Electrical Description] | End: 16Meg X 8 Simm Module | ****************************************************************************** ANALYSIS PATH/DATA THAT LED TO SPECIFICATION: From owner-ibis Fri Mar 7 13:47:15 1997 Received: from icx.com (root@fw.icx.com [205.238.6.33]) by vhdl.vhdl.org (8.8.5/8.8.3) with SMTP id NAA09307 for ; Fri, 7 Mar 1997 13:47:14 -0800 (PST) Received: by icx.com (/\oo/\ Smail3.1.29.1 #29.2) id ; Fri, 7 Mar 97 13:45 PST Received: by icx.com (/\==/\ Smail3.1.28.1 #28.14) id ; Fri, 7 Mar 97 13:45 PST Received: by icx.com (/\==/\ Smail3.1.28.1 #28.16) id ; Fri, 7 Mar 97 13:48 PST Message-Id: Date: Fri, 7 Mar 97 13:48 PST From: scottmc@icx.com (Scott McMorrow) To: ibis@vhdl.org, owner-ibis@vhdl.vhdl.org Subject: Re: Bird 36.2 Stephen, I do not see any accomodation of series pass elements in the path structure for this specification. Many memory modules, MCM's, and boards utilize series resistors and/or more complex filtering structures. It is important to be able to model them explicitly, since they are actual components, rather than a degenerate case of the transmission line descriptor. regards, Scott McMorrow Stramond Corporation > To: ibis@vhdl.org > Subject: Bird 36.2 > Date: Fri, 07 Mar 1997 12:20:07 -0800 > From: Stephen Peters > Status: RO > Hello fellow IBISains: > Per our discussion at the meeting today, here is Bird36.2. This > version includes Bob Ross's comments. Enjoy.... > Regards, > Stephen Peters > Intel Corp. > ------------------ cut here ----------------------------------------- > Buffer Issue Resolution Document (BIRD) > BIRD ID#: 36.2 > ISSUE TITLE: Electric Descriptions of Boards > REQUESTER: Stephen Peters, Hank Herrmann > DATE SUBMITTED: June 23, 1996 > DATE ACCEPTED BY IBIS OPEN FORUM: Pending > ****************************************************************************** > ****************************************************************************** > STATEMENT OF THE ISSUE: There is a need to describe SIMM modules and related > type components that consist of one or more ICs mounted on a PCB board that > connects them to a system thru a set of pins. The following BIRD proposes a > new type of file called .ebd (Electrical Board Description) that > addresses this need. This proposal does not encompass an electrical > description of connectors and other interconnect devices. > ****************************************************************************** > STATEMENT OF THE RESOLVED SPECIFICATIONS: The following text is placed > in the specification after the .pkg file description and before the > [End] keyword description. From owner-ibis Fri Mar 7 17:31:32 1997 Received: from icx.com (root@fw.icx.com [205.238.6.33]) by vhdl.vhdl.org (8.8.5/8.8.3) with SMTP id RAA13152 for ; Fri, 7 Mar 1997 17:31:31 -0800 (PST) Received: by icx.com (/\oo/\ Smail3.1.29.1 #29.2) id ; Fri, 7 Mar 97 17:29 PST Received: by icx.com (/\==/\ Smail3.1.28.1 #28.14) id ; Fri, 7 Mar 97 17:29 PST Received: by icx.com (/\==/\ Smail3.1.28.1 #28.14) id ; Fri, 7 Mar 97 17:31 PST Message-Id: Date: Fri, 7 Mar 97 17:31 PST From: bob@icx.com ( Bob Ross) To: ibis@vhdl.org, scottmc@icx.com Subject: Re: Bird 36.2 Scott: BIRD41.XX should result in series components which can be used in Electrical Board Descriptions when referenced by the [Reference Designator Map]. Best Regards, Bob Ross Interconnectix > Date: Fri, 7 Mar 97 13:48 PST > From: scottmc@icx.com (Scott McMorrow) > To: ibis@vhdl.org, owner-ibis@vhdl.vhdl.org > Subject: Re: Bird 36.2 > Stephen, > I do not see any accomodation of series pass elements > in the path structure for this specification. Many memory > modules, MCM's, and boards utilize series resistors and/or > more complex filtering structures. It is important to be > able to model them explicitly, since they are actual components, > rather than a degenerate case of the transmission line > descriptor. > regards, > Scott McMorrow > Stramond Corporation > > To: ibis@vhdl.org > > Subject: Bird 36.2 > > Date: Fri, 07 Mar 1997 12:20:07 -0800 > > From: Stephen Peters > > Status: RO > > Hello fellow IBISains: > > Per our discussion at the meeting today, here is Bird36.2. This > > version includes Bob Ross's comments. Enjoy.... > > Regards, > > Stephen Peters > > Intel Corp. > > ------------------ cut here ----------------------------------------- > > Buffer Issue Resolution Document (BIRD) > > BIRD ID#: 36.2 > > ISSUE TITLE: Electric Descriptions of Boards > > REQUESTER: Stephen Peters, Hank Herrmann > > DATE SUBMITTED: June 23, 1996 > > DATE ACCEPTED BY IBIS OPEN FORUM: Pending > > ****************************************************************************** > > ****************************************************************************** > > STATEMENT OF THE ISSUE: There is a need to describe SIMM modules and related > > type components that consist of one or more ICs mounted on a PCB board that > > connects them to a system thru a set of pins. The following BIRD proposes a > > new type of file called .ebd (Electrical Board Description) that > > addresses this need. This proposal does not encompass an electrical > > description of connectors and other interconnect devices. > > ****************************************************************************** > > STATEMENT OF THE RESOLVED SPECIFICATIONS: The following text is placed > > in the specification after the .pkg file description and before the > > [End] keyword description. From owner-ibis Mon Mar 10 08:55:40 1997 Received: from ormail.intel.com (ormail.intel.com [134.134.248.3]) by vhdl.vhdl.org (8.8.5/8.8.3) with ESMTP id IAA11282 for ; Mon, 10 Mar 1997 08:55:39 -0800 (PST) Received: from ichips.intel.com (ichips.intel.com [134.134.50.200]) by ormail.intel.com (8.8.4/8.8.4) with ESMTP id IAA25650 for ; Mon, 10 Mar 1997 08:53:43 -0800 (PST) Received: from ichips.intel.com by ichips.intel.com (8.7.4/jIII) id IAA21450; Mon, 10 Mar 1997 08:45:49 -0800 (PST) Message-Id: <199703101645.IAA21450@ichips.intel.com> To: ibis@vhdl.org Subject: Re: Bird 36.2 Date: Mon, 10 Mar 1997 08:53:51 -0800 From: Stephen Peters Hello Scott: First, thank you very much for taking the time to read Bird 36.2 and offer your comments. I agree that the present format does not allow one to call out a descrete, series element in a path except by using the transmission line description with a length parameter as zero. I am willing to modidify the path description format to include this functionality (a reference designator callout for a descrete component), except for one thing. Currently, the IBIS specification does not support a two terminal component description. In other words, a 'series' or 'node' parameter would not be able to reference a legal .ibs file that describes a two terminal device. As Bob Ross pointed out this may change if Bird 41 is accepted, but I hesitate to include functionallity in this BIRD that is only usefull if (or dependednt upon) another BIRD being adopted. So....what does the rest of the forum think? Is this update required, and if it is does that mean we also commit to passing Bird 41? Again Scott, thanks for the feedback. Regards, Stephen Peters Intel Corp. >On Fri, 7 Mar 97 13:48 PST, Scott McMorrow wrote: Stephen, I do not see any accomodation of series pass elements in the path structure for this specification. Many memory modules, MCM's, and boards utilize series resistors and/or more complex filtering structures. It is important to be able to model them explicitly, since they are actual components, rather than a degenerate case of the transmission line descriptor. regards, Scott McMorrow Stramond Corporation From owner-ibis Mon Mar 10 13:26:09 1997 Received: from ormail.intel.com (ormail.intel.com [134.134.248.3]) by vhdl.vhdl.org (8.8.5/8.8.3) with ESMTP id NAA15730 for ; Mon, 10 Mar 1997 13:26:07 -0800 (PST) Received: from ichips.intel.com (ichips.intel.com [134.134.50.200]) by ormail.intel.com (8.8.4/8.8.4) with ESMTP id NAA02997 for ; Mon, 10 Mar 1997 13:24:13 -0800 (PST) Received: from pdx855.intel.com by ichips.intel.com (8.7.4/jIII) id NAA24029; Mon, 10 Mar 1997 13:16:18 -0800 (PST) Received: by pdx855.intel.com (4.1/SW1.11) id AA14591; Mon, 10 Mar 97 13:24:22 PST Message-Id: <9703102124.AA14591@pdx855.intel.com> Subject: Re: Bird 36.2 To: ibis@vhdl.org Date: Mon, 10 Mar 1997 13:24:22 -0800 (PST) From: "David Fogel" X-Mailer: ELM [version 2.4 PL25] Mime-Version: 1.0 Content-Type: text/plain; charset=US-ASCII Content-Transfer-Encoding: 7bit Questions regarding Bird 36.2, 1. How do you specify vias (thru or blind) or pads that add additional capacitance to a trace, like test pads? 2. How do you specify tolerances for all the parameters in Bird 36.2? Nominal values may not be sufficient for doing a thorough SI analysis. David Fogel From owner-ibis Mon Mar 10 17:10:08 1997 Received: from icx.com (fw.icx.com [205.238.6.33]) by vhdl.vhdl.org (8.8.5/8.8.3) with SMTP id RAA19443; Mon, 10 Mar 1997 17:10:07 -0800 (PST) Received: by icx.com (/\oo/\ Smail3.1.29.1 #29.2) id ; Mon, 10 Mar 97 17:07 PST Received: by icx.com (/\==/\ Smail3.1.28.1 #28.14) id ; Mon, 10 Mar 97 17:07 PST Received: by icx.com (/\==/\ Smail3.1.28.1 #28.14) id ; Mon, 10 Mar 97 17:09 PST Message-Id: Date: Mon, 10 Mar 97 17:09 PST From: bob@icx.com ( Bob Ross) To: ibis-users@vhdl.org, ibis@vhdl.org Subject: IBISCHK2+ EXECUTABLES To All: ibischk2+ executables are now available for downloading under ftp://vhdl.org/pub/ibis/ibschk2+ They contain additional checks for data values. They are beta versions at this time, pending feedback from users. Thanks to Chris Rokusek of Quad Design/Viewlogic for providing these executables. Attached is part of the CHANGES document: Best Regards Bob Ross Interconnectix Ibischk2 Users, Version 2.1.3 of ibischk2 contains the following additional checks. 1) Checks ac waveform end points against dc Vi curves. 2) Checks test load Rref to Vref can be driven through Vmeas. 3) Checks for large currents due to inaccurate shunt diodes 4) Checks c_comp for large values ( > 1 nF) 5) Checks r/f ramp_times for large values ( > 1 ms) 6) Checks pin C for large values ( > 1 nF) 7) Checks pin R for large values ( > 1 kOhm) 8) Checks pin L for large values ( > 1 uH) Chris Rokusek Quad Design/Viewlogic crokusek@qdt.com From owner-ibis Tue Mar 11 08:54:46 1997 Received: from icx.com (root@fw.icx.com [205.238.6.33]) by vhdl.vhdl.org (8.8.5/8.8.3) with SMTP id IAA04533 for ; Tue, 11 Mar 1997 08:54:41 -0800 (PST) Received: by icx.com (/\oo/\ Smail3.1.29.1 #29.2) id ; Tue, 11 Mar 97 08:52 PST Received: by icx.com (/\==/\ Smail3.1.28.1 #28.14) id ; Tue, 11 Mar 97 08:52 PST Received: by icx.com (/\==/\ Smail3.1.28.1 #28.14) id ; Tue, 11 Mar 97 08:54 PST Message-Id: Date: Tue, 11 Mar 97 08:54 PST From: bob@icx.com ( Bob Ross) To: ibis@vhdl.org Subject: IBIS MINUTES 3/7/97 DATE: March 11, 1997 SUBJECT: 3/07/97 EIA IBIS Open Forum Minutes VOTING MEMBERS AND 1997 PARTICIPANTS LIST: AMP Jeff Walden Applied Simulation Technology Dileep Divekar*, Norio Matsui Cadence Design C. Kumar*, Don Telian Cypress Bruce Wenniger Digital Equipment Corp. Jeff Chu* Hewlett Packard, EEsof Karl Kachigan, Henry Wu HyperLynx Kellee Crisafulli INCASES Olaf Rethmeier* Intel Corporation Stephen Peters*, Arpad Muranyi*, Interconnectix Bob Ross* Mitsubushi Tam Cao Motorola Ahmed Omer National Semiconductor Syed Huq*, Cheng-Yang Kao, Mike Bristol, Peter Laflamme, Kevin Smith, NCR Dave Moxley*, Richard Mellitz NEC (Hiroshi Matsumoto) Quad Design/Viewlogic Jon Powell, Chris Rokusek* Quantic Laboratories (Mike Ventham) Texas Instruments Thomas Fisher Thomson-CSF/SCTF (Jean LeBrun) UniCAD Canada Ltd. (Celso Faia) Veribest Ian Dodd VLSI Technology Harish Patel, D.C. Sessions, Zuken-Redac (John Berrie) OTHER PARTICIPANTS IN 1997: 3M Fran Hart Actel Scott Schlachter Acuson & Free Model Foundation Richard Munden Alcatel John Fitzpatrick Ansoft Eric Bogatin Apteq Design Systems Dan FitzPatrick Compaq Weston Beal EIA Patti Rusher* EMC Fabrizio Zanella Micron Technology Brian Johnson Molex Gus Panella North Carolina State U. (Michael Steer) S3, Inc. Porsh Shih, Sarathy Sribhashyam Ultratest International Charles Im Zeelan Technology George Opsahl In the list above, attendees at the meeting are indicated by *. Principal members or other active members who have not attended are in parentheses. Participants who no longer are in the organization are in square brackets. Upcoming Meetings: The bridge numbers for future IBIS teleconferences are as follows: Date Bridge Number Reservation # Passcode 3/28/97 (916) 356-9200 2-133309 2774522 All meetings are 8:00 AM to 9:55 AM Pacific Time. We try to have agendas out 7 days before each open forum and meeting minutes out within 7 days after. When you call into the meeting, ask for the IBIS Open Forum hosted by Will Hobbs and give the reservation number and passcode. NOTE: "AR" = Action Required. -------------------------------- MINUTES ------------------------------------- INTRODUCTIONS AND MEETING QUORUM Jeff Chu reported that Digital Equipment Corporation is a full EIA/IBIS member. MEMBERSHIP UPDATE AND TREASURER'S REPORT Patti Rusher shows $10,129 in the EIA/IBIS account, with about $6,500 in 1997 membership dues pending. She listed the members still owing payment. REVIEW OF MINUTES AND AR'S No Changes. MISCELLANY/ANNOUNCEMENTS Bob Ross reported that the presentations from the EIA/IBIS Summit meeting of January 20, 1997 are now available on vhdl.org under: ftp://vhdl.org/pub/ibis/summits/summit97 Also, the draft Version 3.0 of IBIS has been updated in the /pub/ibis/wip directory to ver3_0f.ibs to include the most recently passed BIRDs. PRESS AND WEB PAGE UPDATES Bob Ross reported that Applied Simulation Technology's IBIS products are mentioned on page 69 of Printed Circuit Design, March 1997 under PCB Design Conference West Product Preview. Syed Huq reported that he has completed converting his Electronic Design article to HTML, and he will be mailing it on to Patti Rusher to be put on the EIA/IBIS home page. He will establish a link to the s2ibis utility available through the VeriBest home page. He has received permission to copy an HTML version of the IBIS Cookbook from Andreas Thiel of Zurich, Switzerland. Finally, an HTML version of the IBIS roster will be available which will have direct e-mail address links. Syed reported that the text version will still be available on vhdl.org/pub/ibis/roster for easier downloading. Bob and Syed will keep in sync on roster changes. NEW MODELS AVAILABLE, LIBRARY UPDATE [Syed Huq reports after the meeting that National Semiconductor has released two IBIS models which are 3.3V LVDS line drivers and receivers: ds901v031.ibs and ds901v032tm.ibs. These are available on the National model site.] Chris Rokusek reported working with Texas Instruments on a question concerning the test load for timing for a differential pin. Ideally, the load should be differential. However, IBIS supports only single-ended Thevenin equivalents. Bob Ross suggested a possible "Rdiff" test load might be preferred. However, both Bob and Chris reported good results with the single-ended load currently in place. Bob reported that Cypress Semiconductor with plans to make IBIS models available in the future under a new page: http://www.cypress.com/tech_sup/web_tech/ibis_top.html A new mpc2605.ibis model is now available under the Motorola Power PC section of the Motorola IBIS models. Also Motorola now lists direct links (although not working yet) to their FAST SRAM IBIS models: http://www.mot.com/SPS/FastSRAM/models/IBIS.html OPENS FOR NEW ISSUES Bob Ross on ground/power bounce model extensions (not discussed) DESIGN AUTOMATION CONFERENCE 1997 IBIS MEETING PLANNING Patti Rusher asked if the IBIS Summit meeting will be held all day on Thursday, June 12, 1997 and received confirmation. The deadlines for poster information to be sent to the graphic artist is March 21. Bob Ross will ask Jon Powell if he can help with this. Patti will be sending by express mail the necessary information. We expect IBIS literature to be distributed at the Conference. INTERNATIONAL PROGRESS Patti Rusher stated that Greg Ledenbach of Sematech has provided this update: IBIS, Version 2.1 NP (New work item Proposal) (93/46/NP) passed with 6 out of 6 voting members and prepared to participants. For reference, four out of the five NPs passed. EIA JAPAN I/O INTERFACE MODEL PROPOSAL Bob Ross reported that a committee meeting is planned, Wednesday, March 19, 1997 at the Santa Clara Convention Center during the PCB West Design Conference. The purpose is for Electronic Industries Association of Japan (EIAJ) Committee Chair Hideki Fukuda from Hitachi to present "Standard for I/O Interface Model", Draft Version 0.0. Several IBIS Committee participants have expressed interest and have been mailed a copy. There will be room for a few more interested IBIS participants who are attending the PCB Conference but please let Bob know beforehand. Current invited participants are: Bob Ross, Interconnectix Syed Huq, National Semiconductor Jon Powell, Quad Design/Viewlogic Will Hobbs, Intel Patti Rusher, EIA Stephen Peters, Intel Dileep Divekar, Applied Simulation Technology (USA) C. Kumar, Cadence Shinichi Maeda, KAW/USA Patti Rusher has scheduled the Bayshore West Room from 8 A.M. to 2 P.M. for about 15 people at the Westin Hotel which adjoins the Convention Center. Bob plans the actual meeting to start at 9 AM. Refreshments will be provided. Bob and Fukuda-san will be developing the schedule. In a note to Bob, Fukuda-san outlined his general expectations for the EIAJ activity: Draft Version 0.0: Get CAE Vendor support and cooperation from the EIA/IBIS Open Forum. Draft Version 1.0: Get Semiconductor Company Commitment. Draft Version 2.0: Get Customer support and model providers and processors produce systems to support the Specification. Release: Release hopefully by the end of the year. Stephen Peters asked who was behind the EIAJ activity, and Bob responded that a group of 17 Japanese companies (including Japanese representative from some American companies). Patti asked if the draft should be forwarded to IEC, but Bob responded that the proposal was not ready yet. There is a potential problem with forwarding overlapping standards. Bob indicated that he felt the effort had a number of distinct elements to set it apart from IBIS, and he expected that IBIS will continue along its current course. C. Kumar noted that multiple standards are expensive for the industry and also noted that IBIS and EIAJ activities could have some overlapping package models. ELECTRONIC DESIGN REPRINTS As previously noted Syed Huq is posting an HTML electronic copy of his article "Ease System Simulation With IBIS Device Models" published in the December 2, 1996 issue of Electronic Design on the EIA/IBIS Home page. Hardcopies are useful for handouts at shows, particularly at DAC97. Bob Ross indicated that the reprints cost: 100 $2010 500 $2215 1000 $2715 Bob proposed that the EIA/IBIS Open Forum purchase 1000. However, Patti Rusher and Stephen Peters felt that 500 would be adequate. By unanimous consent, the Open Forum voted to purchase 500 copies. AR - Syed Huq contact Patti Rusher with information on purchasing the reprints. Syed noted that he will send back about 150 copies of the older 1995 EDN article to Patti to also be used at shows along with the ED article reprints. ROSTER UPDATE Syed Huq and Bob Ross are coordinating roster updates. The new roster has five non-EIA/IBIS member companies deleted who have not responded. Syed volunteered to work on the contacts.txt list to update it and to produce an HTML version. IBIS COOKBOOK PROGRESS Stephen Peters states that an internal version is nearing completion, and he will be reviewing it shortly. He needs to sanitize it by taking out Intel- specific information before releasing it. He requested Chris Rokusek to provide him the test load information for waveforms for inclusion. Bob Ross indicated that this will be valuable tutorial material in response to some recent reflector discussion. BIRD41.1 - MODELING SERIES SWITCHABLE DEVICES Bob Ross had indicated that the author of BIRD41.1, John Fitzpatrick, was on vacation. So Bob went over BIRD41.1 in some detail, both for explanation and also to raise some technical concerns. Some of the points are presented here. BIRD41.1 Consists of two additions: Under [Component], [Series Pin] is defined to associate two pins with a series model. Under [Model], two new Model_types (Series, and Series_switch) are defined. Several Series keywords are introduced to provide the electrical description. BIRD41.1 handles both discrete series elements (series diodes, resistors, capacitors, etc. and also series switches such as represented by the Texas Instruments CBT technology and by the Quality Semiconductor Quick Switch technology. In fact, these devices should drive what features are included in BIRD41.1 for series switch elements. Regarding the [Series Pin], under [Component], Bob had these points: 1. Is non-symmetrical operation really needed? It will lead to problems in other areas. 2. The State table syntax needs to be standardized and restricted. "OFF", "ON" and "NA" may be restricted suggestions. However, a more general grouping method may be needed to relate to "Function Table" states. 3. The data books give "Function Table" logic descriptions of the components. The Series_switch is a case where IBIS should embed some of the logic choices in the model to reduce, in most cases, the combined OFF-ON permutations. This is discussed later. Regarding the [Model] keyword additions: 1. Just [Rseries], [Lseries], and [Cseries] are needed. The proposed [R_c_series], [L_c_series] and [R_l_series] additions are unnecessary. All series elements should be allowed to be connected in series, just as the "Terminator" model elements (such as [Rpower], [Rgnd], [Gnd Clamp], [Power Clamp and [Rac]&[Cac]) can all be used in one [Model] and connected in parallel. 2. The [Series Impedance] table can also be connected in series. 3. The [Series Impedance] table could be defined with a voltage range of -Vcc to Vcc for closed switch operation or low impedance, It could also have a range from -2Vcc to 2Vcc for open operation. So its range needs to be defined. The full ranges take care of Pin1-to-Pin2 and Pin2-to-Pin1 non-symmetrical operation. 4. R_load is not needed. 5. Also the Mode subparameter could be dropped. This could be handled another way for actual switches. One suggestion for Series_switch devices might be to introduce an [On] and an [Off] set of keywords under which the two states are described. The simplest description can be done by just using low and high values of [Rseries]. Some general comments are: 1. The [Pin] keyword is still required as part of the [Component] pinout description. 2. There is no restriction on possible [Pin] model descriptions including GND, POWER, NC when the pin is also listed as a series pin. This is a potential advantage since the [Pin] model itself could still be used for describing any clamping structure for protection on the correct pin. Drivers could be put on one side. The package description methods and all possible extensions under the [Pin] structure remain unchanged. There are some questions: 1. What does C_comp mean in a series model? 2. Should a Series Pin be used to connect to a supply or ground, as proposed above? 3. Should the Series Pins be used for Differential terminations? 4. Can several different series pin models be connected to the same pin? The final discussion consisted of elaborating on the "Function Table" for series switches, as described in data books. Bob illustrated the need for such a Function Table to allow the user interface or simulator controlled operation to provide only the switch combinations that the device actually supports (rather than all possible switch setting permutations of the component). Several Components were used as examples: 1. TI SN74CBT3125 Quadruple Bus Switch has 4 independent switches which can be turned ON or OFF - 16 combinations. 2. TI SN74CBT3245 Octal Bus Switch has 8 dependent switches, all OFF or all ON - 2 combinations. 3. TI SN74CBT3244 Octal Bus Switch has 8 switches of 2 groups of 4 dependent configurations where each group can be OFF or ON - 4 combinations. 4. Quality QS3251 QuickSwitch 8:1 Mux/Demux has 8 switches which can be all OFF or configured with only one switch to be ON at a time to connect one of 8 lines to a second pin - 9 combinations. 5. TI SN74CBT3383 10 Bit Bus-Exchange Switch describes 5 sets of exchange switches which ALL either connect-directly two lines, cross-over- connect two lines, or provide no connections - 3 combinations. 6. (Not discussed was a case such as the TI SN74CBT6800 with 10 switches for direct connection and 10 switches for precharge bias, ALL of which are synchronized - 2 combinations.) Arpad Muranyi raised the issue whether BIRD41.1 should capture the dynamic turn-on and turn-off characteristics of a switch. Bob suggested that there was sufficient complication already without this addition. Also, Bob was not aware of a defined need. Furthermore Arpad questioned whether the group switching was too much of a "logic" issue to be in IBIS. Bob stated that a form of group change logic was already approved in Arpad's BIRD30.2 for Switching Buffer Models. Arpad wondered if IBIS should extend into Analog and Mixed Signal domains. However, someone stated that this would enter the domain where HDL languages exist. C. Kumar stated that the mission of IBIS should be where IBIS is best positioned - a higher level behavioral modeling format for analog interface analysis. Bob agreed. Steve Peters indicated that he had worked with designs using series switches. Dave Moxley also indicated that he has used series switches. He stressed the need for a good user interface since the current way he describes series switches is to manually change the values of series resistors. Arpad questioned whether some existing table keywords should be re-used, and Bob responded that, in his opinion, it was better to define a new keyword if there was any difference in usage. AR - Bob Ross write up the comments regarding BIRD41.1. Bob also work with John Fitzpatrick concerning any changes. PACKAGE COMMITTEE REPORT Stephen Peters stated that Jon Powell did not receive all of the Connector Spice model and matrix information, and that he will be delayed in doing the planned Spice and matrix model correlation study. He expects to produce a proposal which includes syntax for allowing a smaller model subsection to describe a full connector model, if possible. The next Package Committee meeting is scheduled for Friday, March 14, 1997. BIRD36.1 - ELECTRICAL DESCRIPTION OF BOARDS Stephen Peters received Bob Ross' comments. He generally agrees with the technical comments including that a Pin can exist only once as part of a path description in the file. AR - Stephen Peters issue BIRD36.2 with the suggested changes. [Done] Bob proposed with Stephen's concurrence that BIRD36.2 would be scheduled for a vote at the next meeting. VERSION 3.0 FUNCTIONALITY Stephen Peters questioned what will be in Version 3.0, and Bob Ross briefly stated that the planned functionality includes all approved BIRDs and these pending proposals: BIRD36.2, a connector model BIRD, and possibly BIRD41.x. Also last-minute possibilities are early clamps and some more ground/power bounce details. Bob hopes that we can target the DAC97 meeting in June (or the meeting before) for final closure of all issues and for Version 3.0 ratification. C. Kumar raised the issue of correlation of IBIS simulations with Spice simulations. Syed Huq indicated that aside from ApsimIBIS from Applied Simulation Technology, there were no utilities that could produce Spice models from IBIS models. (Avanti! - Meta-software has withdrawn from the market.) Dileep Divekar indicated that ApsimIBIS produces Spice models compatible ApsimSpice only. Bob Ross deferred the correlation discussion and IBIS to Spice tool generation issue to the next meeting. MODELING EARLY CLAMPS IN IBIS Arpad Muranyi reported that at this time he has focused his initial research (with assistance from C. Kumar) on describing appropriate measurements for electrical description. The formatting details are not the difficult issue. He is planning a BIRD proposal for Version 3.0. PARSER STATUS Chris Rokusek plans to send his ibischk2 extensions to resolve BUGs 5-7 to Bob Ross for posting on vhdl.org. Only the executables will be posted since the source code is available only through purchase of a license. After some testing by the users, Chris may provide the enhanced code as the new base- line for future ibischk3 development for Version 3.0 of IBIS. BUG8 - RESERVED WORDS USED AS PINNUMBERS GENERATE ERRORS Bob Ross indicated that BUG8 has been in existence since the first ibis_chk parser. The IBIS specification could be interpreted to mean that this is not a bug. Bob did not recommend changing the parser at this time, but rather to classify it as an annoyance, with no fix. There are easy work- arounds. Stephen Peters proposed that BUG8 be fixed as part of the Version 3.0 ibischk3 development project. After some brief discussion, everyone concurred by unanimous vote that BUG8 will be fixed in ibischk3. Bob noted that the current release of s2ibis2_ver1.1 contains examples which has "gnd" as the IBIS file pin number, and this will generate an ibischk2 error message. NEXT MEETING: The next meeting is on Friday, March 28, 1996, 8:00 A.M. to 9:55 A.M. BIRD36.2 is scheduled for a vote. ============================================================================== NOTES IBIS CHAIR: Bob Ross (503) 603-2523, Fax (503) 639-3469 bob@icx.com Modeling Engineer, Interconnectix 10220 SW Nimbus Ave, K4, Portland, OR 97223 VICE CHAIR: Syed Huq (408) 721-4874, Fax: (408) 721-4785 huq@rockie.nsc.com Staff Applications Engineer, National Semiconductor, M/S A-2595 2900 Semiconductor Drive, Santa Clara, CA 95052 LIBRARIAN: Jon Powell (805) 988-8250, Fax: (805) 988-8259 jonp@qdt.com Transmission-Line Products Manager, Quad Design/Viewlogic 1385 Del Norte Rd., Camarillo, CA 93010 SECRETARY: Vacant This meeting was conducted in accordance with the EIA Legal Guides and EIA Manual of Organization and Procedure. The following e-mail addresses are used: ibis-request@vhdl.org To join, change, or drop from either the IBIS Open Forum Reflector (ibis@vhdl.org), the IBIS Users' Group Reflector (ibis-users@vhdl.org) or both. State your request. ibis-info@vhdl.org To obtain general information about IBIS, to ask specific questions for individual response, and to inquire about joining the EIA-IBIS Open Forum as a full Member. ibis@vhdl.org To send a message to the general IBIS Open Forum Reflector. This is used mostly for IBIS Standardization business and future IBIS technical enhancements. ibis-users@vhdl.org To send a message to the IBIS Users' Group Reflector. This is used mostly for IBIS clarification, current modeling issues, and general user concerns. ibischk-bug@vhdl.org To report ibischk2 parser bugs. The Bug Report Form Resides on vhdl.org in /pub/ibis/bugs/bugform.txt along with reported bugs. Information on IBIS technical contents, IBIS participants, and actual IBIS models are available on the IBIS Home page found by selecting the Electronic Information Group under: http://www.eia.org Check the pub/ibis directory on vhdl.org for more information on previous discussions and results. You can get on via ftp anonymous, or send an e-mail request to the automatic archive server, archive@vhdl.org. "IBIS Spoken Here" placards are available from Jon Powell (jonp@qdt.com) for use at trade shows. ============================================================================== From owner-ibis Tue Mar 11 18:29:34 1997 Received: from newsgw.mentorg.com (newsgw.mentorg.com [137.202.128.5]) by vhdl.vhdl.org (8.8.5/8.8.3) with SMTP id SAA14186 for ; Tue, 11 Mar 1997 18:29:31 -0800 (PST) Received: from naf.wv.mentorg.com by newsgw.mentorg.com (8.6.8.1/CF5.22R) id SAA19698; Tue, 11 Mar 1997 18:27:45 -0800 Received: from pdxml2.mentorg.com by naf.wv.mentorg.com (8.6.8.1/CF5.22R) id SAA08769; Tue, 11 Mar 1997 18:24:52 -0800 Message-ID: Date: 12 Mar 1997 10:57:41 -0800 From: "Alvin Ni" Subject: subscribe To: "IBIS" X-Mailer: Mail*Link SMTP-QM 3.0.2 Subject: Time: 10:35 AM OFFICE MEMO subscribe Date: 3/12/97 subscribe From owner-ibis Wed Mar 12 08:40:29 1997 Received: from icx.com (root@fw.icx.com [205.238.6.33]) by vhdl.vhdl.org (8.8.5/8.8.3) with SMTP id IAA27782 for ; Wed, 12 Mar 1997 08:40:25 -0800 (PST) Received: by icx.com (/\oo/\ Smail3.1.29.1 #29.2) id ; Wed, 12 Mar 97 08:38 PST Received: by icx.com (/\==/\ Smail3.1.28.1 #28.14) id ; Wed, 12 Mar 97 08:38 PST Received: by icx.com (/\==/\ Smail3.1.28.1 #28.14) id ; Wed, 12 Mar 97 08:40 PST Message-Id: Date: Wed, 12 Mar 97 08:40 PST From: bob@icx.com ( Bob Ross) To: ibis@vhdl.org Subject: BIRD41.1 Comments To John Fitzpatrick and IBIS Forum: At the March 7, 1997 EIA/IBIS Open Forum Meeting I provide a few comments on BIRD41.1. One fundamental problem I had was that many series switch devices have a restricted set of switch states that are described in data book function tables. The comments below attempt to address this issue by providing an additional keyword [Series Pin Table] to be used if needed with the [Series Pin] keyword. This table describes the allowable switch states for the component. To test out the syntax proposal, I have provided a brief description and six examples. I still have some questions regarding whether the syntax needs to be more compact or more general. Also attached at the end for reference are the notes from the March 7, 1997 minutes. These notes provide the context for which the examples apply and also raise some other questions. I believe the series and series switch functionality as proposed by John Fitzpatrick is very useful and needed for Version 3.0 of IBIS. I look forward to working the issues related to getting BIRD41.1 approved. Bob Ross Interconnectix COMMENTS REGARDING SERIES PIN TABLE FOR SERIES SWITCH A possible addition to BIRD41.1 is presented here to describe allowable settings associated with a series switch component. Six examples follow to illustrate the syntax. In the examples, [On] and [Off] keywords are used to tag the On and Off states of a Series_switch [Model]. Note, all [Rseries] elements below could also be [Series Impedance] tables. Keyword: [Series Pin Table] Required: No Description: Used to define allowable switching combinations of series switches described in the [Series Pin Table]. Sub-params: On, Off, All Usage Rules: Each state line contains an allowable configuration. A typical state line will start with 'On' followed by all of the on-state group names, and then 'Off' followed by all of the off-state group names. The state line is terminated with the slash '/', even if it extends over several lines to fit within the 80 character column width restriction. The group names in the Function Table Group are used to associate switches whose swithing action is controlled by a common control. The first state line defines the assumed (default) state of the series switch. Other states are selected through a user interface or through automatic control. For devices where all of the switches can be operated independently of each other, the 'All' subparameter can be used just to list the available switches with All modes. The first state line needs to be given explicitly to define the assumed (default) state of the series switch. Examples: |************************************************************************** | SN74CBT3125 Quadruple Bus Switch [Pin] .... [Series Pin Table] | Function Group States On 1 2 3 4 Off / | Default setting is all switched On. | | All 1 2 3 4 / | This line could be used instead of the explicit | listing of combinations below. | On Off 1 2 3 4 / | All Off setting. On 1 Off 2 3 4 / | Other possible combinations below. On 2 Off 1 3 4 / On 3 Off 1 2 4 / On 4 Off 1 2 3 / | Note, if there were 8 switches, then 2^8 combinations On 1 2 Off 3 4 / | would have to be listed. On 1 3 Off 2 4 / On 1 4 Off 2 3 / On 2 3 Off 1 4 / On 2 4 Off 1 3 / On 3 4 Off 1 2 / On 1 2 3 Off 4 / On 1 2 4 Off 3 / On 1 3 4 Off 2 / On 2 3 4 Off 1 / [Series Pin] | Pin1 Pin2 Model_name Function Table Group | 2 3 CBT3125Series 1 | Four Independent Groups 5 6 CBT3125Series 2 9 8 CBT3125Series 3 12 11 CBT3125Series 4 | .... [Model] CBT3125Series Model_type Series_switch ... [On] [Rseries] 2 1 5 [Off] [Rseries] 500M 400M 600M ... |************************************************************************** | SN74CBT3245 Octal Bus Switch [Pin] .... [Series Pin Table] | Function Group States On 1 Off / | Default setting is On. On Off 1 / | Off state. [Series Pin] | Pin1 Pin2 Model_name Function Table Group | 2 18 CBT3245Series 1 | All switches in sync 3 17 CBT3245Series 1 4 16 CBT3245Series 1 5 15 CBT3245Series 1 6 14 CBT3245Series 1 7 13 CBT3245Series 1 8 12 CBT3245Series 1 9 11 CBT3245Series 1 | .... [Model] CBT3245Series Model_type Series_switch ... [On] [Rseries] 2 1 5 [Off] [Rseries] 500M 400M 600M ... |************************************************************************** | SN74CBT3244 Octal Bus Switch [Pin] .... [Series Pin Table] | Function Group States On 1 2 Off / | Default setting is all switched On. On 1 Off 2 / On 2 Off 1 / On Off 1 2 / [Series Pin] | Pin1 Pin2 Model_name Function Table Group | 2 18 CBT3244Series 1 | First Group 4 16 CBT3244Series 1 6 14 CBT3244Series 1 8 12 CBT3244Series 1 11 9 CBT3244Series 2 | Second Group 13 7 CBT3244Series 2 15 5 CBT3244Series 2 17 3 CBT3244Series 2 | .... [Model] CBT3244Series Model_type Series_switch ... [On] [Rseries] 2 1 5 [Off] [Rseries] 500M 400M 600M ... |************************************************************************** | QS3251 QuickSwitch 8:1 Mux/Demux [Pin] .... [Series Pin Table] | Function Group States On Off 1 2 3 4 5 6 7 8 / | Default setting is all switches Off. On 1 Off 2 3 4 5 6 7 8 / On 2 Off 1 3 4 5 6 7 8 / On 3 Off 1 2 4 5 6 7 8 / On 4 Off 1 2 3 5 6 7 8 / On 5 Off 1 2 3 4 6 7 8 / On 6 Off 1 2 3 4 5 7 8 / On 7 Off 1 2 3 4 5 6 8 / On 8 Off 1 2 3 4 5 6 7 / [Series Pin] | Pin1 Pin2 Model_name Function Table Group | 4 5 QS3251Series 1 3 5 QS3251Series 2 2 5 QS3251Series 3 1 5 QS3251Series 4 15 5 QS3251Series 5 14 5 QS3251Series 6 13 5 QS3251Series 7 12 5 QS3251Series 8 | .... [Model] QS3251Series Model_type Series_switch ... [On] [Rseries] 2 1 5 [Off] [Rseries] 500M 400M 600M ... |************************************************************************** | SN74CBT3383 Bus-Exchange Switch [Pin] .... [Series Pin Table] | Function Group States On 1 Off 2 / | First Entry is the Default. On 2 Off 1 / | Cross Over Mode On Off 1 2 / | All Off [Series Pin] | Pin1 Pin2 Model_name Function Table Group | 3 2 CBT3383Series 1 | Straight Thru Mode 4 5 CBT3383Series 1 3 5 CBT3383Series 2 | Cross Over Mode 4 2 CBT3383Series 2 | 7 6 CBT3383Series 1 | Straight Thru Mode 8 9 CBT3383Series 1 7 9 CBT3383Series 2 | Cross Over Mode 8 6 CBT3383Series 2 | 11 10 CBT3383Series 1 | Straight Thru Mode 12 13 CBT3383Series 1 11 13 CBT3383Series 2 | Cross Over Mode 12 10 CBT3383Series 2 | 17 16 CBT3383Series 1 | Straight Thru Mode 18 19 CBT3383Series 1 17 19 CBT3383Series 2 | Cross Over Mode 18 16 CBT3383Series 2 | 21 20 CBT3383Series 1 | Straight Thru Mode 22 23 CBT3383Series 1 21 23 CBT3383Series 2 | Cross Over Mode 22 20 CBT3383Series 2 | .... [Model] CBT3383Series Model_type Series_switch ... [On] [Rseries] 2 1 5 [Off] [Rseries] 500M 400M 600M ... |************************************************************************** | SN74CBT6800 10 Bus Switch with Precharged Outputs for Live Insertion [Pin] .... [Series Pin Table] | Function Group States On 1 Off / | First Entry is the Default. On Off 1 / | Precharge State [Series Pin] | Pin1 Pin2 Model_name Function Table Group | 2 23 CBT6800Series 1 3 22 CBT6800Series 1 4 21 CBT6800Series 1 5 20 CBT6800Series 1 6 19 CBT6800Series 1 7 18 CBT6800Series 1 8 17 CBT6800Series 1 9 16 CBT6800Series 1 10 15 CBT6800Series 1 11 14 CBT6800Series 1 23 13 CBT6800Precharge 1 | Precharge is connected to bias 22 13 CBT6800Precharge 1 | pin 13. 21 13 CBT6800Precharge 1 20 13 CBT6800Precharge 1 19 13 CBT6800Precharge 1 18 13 CBT6800Precharge 1 17 13 CBT6800Precharge 1 16 13 CBT6800Precharge 1 15 13 CBT6800Precharge 1 14 13 CBT6800Precharge 1 | .... [Model] CBT6800Series Model_type Series_switch ... [On] [Rseries] 2 1 5 [Off] [Rseries] 500M 400M 600M [Model] CBT6800Precharge Model_type Series_switch ... [On] [Rseries] 500M 400M 600M | No resistance in the On state [Off] [Rseries] 10k 15k 8k | Precharge bias resistance ... |************************************************************************** |************************************************************************** COMMENTS FROM MARCH 7, 1997 MINUTES FOR REFERENCE BIRD41.1 - MODELING SERIES SWITCHABLE DEVICES Bob Ross had indicated that the author of BIRD41.1, John Fitzpatrick, was on vacation. So Bob went over BIRD41.1 in some detail, both for explanation and also to raise some technical concerns. Some of the points are presented here. BIRD41.1 Consists of two additions: Under [Component], [Series Pin] is defined to associate two pins with a series model. Under [Model], two new Model_types (Series, and Series_switch) are defined. Several Series keywords are introduced to provide the electrical description. BIRD41.1 handles both discrete series elements (series diodes, resistors, capacitors, etc. and also series switches such as represented by the Texas Instruments CBT technology and by the Quality Semiconductor Quick Switch technology. In fact, these devices should drive what features are included in BIRD41.1 for series switch elements. Regarding the [Series Pin], under [Component], Bob had these points: 1. Is non-symmetrical operation really needed? It will lead to problems in other areas. 2. The State table syntax needs to be standardized and restricted. "OFF", "ON" and "NA" may be restricted suggestions. However, a more general grouping method may be needed to relate to "Function Table" states. 3. The data books give "Function Table" logic descriptions of the components. The Series_switch is a case where IBIS should embed some of the logic choices in the model to reduce, in most cases, the combined OFF-ON permutations. This is discussed later. Regarding the [Model] keyword additions: 1. Just [Rseries], [Lseries], and [Cseries] are needed. The proposed [R_c_series], [L_c_series] and [R_l_series] additions are unnecessary. All series elements should be allowed to be connected in series, just as the "Terminator" model elements (such as [Rpower], [Rgnd], [Gnd Clamp], [Power Clamp and [Rac]&[Cac]) can all be used in one [Model] and connected in parallel. 2. The [Series Impedance] table can also be connected in series. 3. The [Series Impedance] table could be defined with a voltage range of -Vcc to Vcc for closed switch operation or low impedance, It could also have a range from -2Vcc to 2Vcc for open operation. So its range needs to be defined. The full ranges take care of Pin1-to-Pin2 and Pin2-to-Pin1 non-symmetrical operation. 4. R_load is not needed. 5. Also the Mode subparameter could be dropped. This could be handled another way for actual switches. One suggestion for Series_switch devices might be to introduce an [On] and an [Off] set of keywords under which the two states are described. The simplest description can be done by just using low and high values of [Rseries]. Some general comments are: 1. The [Pin] keyword is still required as part of the [Component] pinout description. 2. There is no restriction on possible [Pin] model descriptions including GND, POWER, NC when the pin is also listed as a series pin. This is a potential advantage since the [Pin] model itself could still be used for describing any clamping structure for protection on the correct pin. Drivers could be put on one side. The package description methods and all possible extensions under the [Pin] structure remain unchanged. There are some questions: 1. What does C_comp mean in a series model? 2. Should a Series Pin be used to connect to a supply or ground, as proposed above? 3. Should the Series Pins be used for Differential terminations? 4. Can several different series pin models be connected to the same pin? The final discussion consisted of elaborating on the "Function Table" for series switches, as described in data books. Bob illustrated the need for such a Function Table to allow the user interface or simulator controlled operation to provide only the switch combinations that the device actually supports (rather than all possible switch setting permutations of the component). Several Components were used as examples: 1. TI SN74CBT3125 Quadruple Bus Switch has 4 independent switches which can be turned ON or OFF - 16 combinations. 2. TI SN74CBT3245 Octal Bus Switch has 8 dependent switches, all OFF or all ON - 2 combinations. 3. TI SN74CBT3244 Octal Bus Switch has 8 switches of 2 groups of 4 dependent configurations where each group can be OFF or ON - 4 combinations. 4. Quality QS3251 QuickSwitch 8:1 Mux/Demux has 8 switches which can be all OFF or configured with only one switch to be ON at a time to connect one of 8 lines to a second pin - 9 combinations. 5. TI SN74CBT3383 10 Bit Bus-Exchange Switch describes 5 sets of exchange switches which ALL either connect-directly two lines, cross-over- connect two lines, or provide no connections - 3 combinations. 6. (Not discussed was a case such as the TI SN74CBT6800 with 10 switches for direct connection and 10 switches for precharge bias, ALL of which are synchronized - 2 combinations.) Arpad Muranyi raised the issue whether BIRD41.1 should capture the dynamic turn-on and turn-off characteristics of a switch. Bob suggested that there was sufficient complication already without this addition. Also, Bob was not aware of a defined need. Furthermore Arpad questioned whether the group switching was too much of a "logic" issue to be in IBIS. Bob stated that a form of group change logic was already approved in Arpad's BIRD30.2 for Switching Buffer Models. Arpad wondered if IBIS should extend into Analog and Mixed Signal domains. However, someone stated that this would enter the domain where HDL languages exist. C. Kumar stated that the mission of IBIS should be where IBIS is best positioned - a higher level behavioral modeling format for analog interface analysis. Bob agreed. Steve Peters indicated that he had worked with designs using series switches. Dave Moxley also indicated that he has used series switches. He stressed the need for a good user interface since the current way he describes series switches is to manually change the values of series resistors. Arpad questioned whether some existing table keywords should be re-used, and Bob responded that, in his opinion, it was better to define a new keyword if there was any difference in usage. AR - Bob Ross write up the comments regarding BIRD41.1. Bob also work with John Fitzpatrick concerning any changes. From owner-ibis Wed Mar 12 08:56:33 1997 Received: from ormail.intel.com (ormail.intel.com [134.134.248.3]) by vhdl.vhdl.org (8.8.5/8.8.3) with ESMTP id IAA28102 for ; Wed, 12 Mar 1997 08:56:32 -0800 (PST) Received: from ichips.intel.com (ichips.intel.com [134.134.50.200]) by ormail.intel.com (8.8.4/8.8.4) with ESMTP id IAA01703 for ; Wed, 12 Mar 1997 08:54:38 -0800 (PST) Received: from ichips.intel.com by ichips.intel.com (8.7.4/jIII) id IAA02275; Wed, 12 Mar 1997 08:46:28 -0800 (PST) Message-Id: <199703121646.IAA02275@ichips.intel.com> To: ibis@vhdl.org Subject: Re: Bird 36.2 Date: Wed, 12 Mar 1997 08:54:47 -0800 From: Stephen Peters Hello David: My comments below, prefixed with >>> Regards, Stephen Peters Intel Corp. Questions regarding Bird 36.2, 1. How do you specify vias (thru or blind) or pads that add additional capacitance to a trace, like test pads? >>> If I understand your question properly, a via or pad can be specified as a C or L/C in the path just like any other element. For example [Path Description] example J1 Len = 1.0 C=2.5p L=1.0n \ | a lenght of trace Len = 0 C= 0.5p \ | a via Len = 0.7 C=2.0p L=2.0n \ | a second length of trace on a | different layer 2. How do you specify tolerances for all the parameters in Bird 36.2? Nominal values may not be sufficient for doing a thorough SI analysis. >>> Good point. Currently there is no way to specify a tolerance for the L/R/C parameters of a section. I would suggest that if you have 'min' and 'max' Zo/Tpd parameters for the board then several different .edb file could be provided. (As an aside, I wonder if PC boards really have 'min' and 'max' corners as with a silicon I/O buffer, or if accounting for board variations is something that is handeled in the simulator itself via some statistical (Monto Carlo) analysis. Comments?) David Fogel From owner-ibis Wed Mar 12 09:39:57 1997 Received: from icx.com (root@fw.icx.com [205.238.6.33]) by vhdl.vhdl.org (8.8.5/8.8.3) with SMTP id JAA28821 for ; Wed, 12 Mar 1997 09:39:56 -0800 (PST) Received: by icx.com (/\oo/\ Smail3.1.29.1 #29.2) id ; Wed, 12 Mar 97 09:36 PST Received: by icx.com (/\==/\ Smail3.1.28.1 #28.14) id ; Wed, 12 Mar 97 09:36 PST Received: by icx.com (/\==/\ Smail3.1.28.1 #28.14) id ; Wed, 12 Mar 97 09:38 PST Message-Id: Date: Wed, 12 Mar 97 09:38 PST From: bob@icx.com ( Bob Ross) To: dfogelx@ichips.intel.com, ibis@vhdl.org, sjpeters@ichips.intel.com Subject: Re: Bird 36.2 David: Here are some responses which add on to Stephen's responses. When you need details concerning vias and test pads, you most likely need the physical database itself. The electrical data base of BIRD36.2 could also approximate some of these effects with appropriate IBIS terminator models for capacitance, etc. It looks like you may need several board models for board tolerance information. The IBIS models can have the Component tolerance information. In general, the electrical board description fills an area where the physical description is not available for an existing board, or where the board has not been physically designed. So the electrical board description may lack some detail. Best Regard, Bob Ross Interconnectix > To: ibis@vhdl.org > Date: Mon, 10 Mar 1997 13:24:22 -0800 (PST) > From: "David Fogel" > Questions regarding Bird 36.2, > 1. How do you specify vias (thru or blind) or pads that add additional > capacitance to a trace, like test pads? > 2. How do you specify tolerances for all the parameters in Bird 36.2? > Nominal values may not be sufficient for doing a thorough SI analysis. > David Fogel From owner-ibis Wed Mar 12 12:40:45 1997 Received: from ns.newbridge.com (ns.newbridge.com [192.75.23.67]) by vhdl.vhdl.org (8.8.5/8.8.3) with SMTP id MAA01764 for ; Wed, 12 Mar 1997 12:40:42 -0800 (PST) Received: (from smap@localhost) by ns.newbridge.com (8.6.12/8.6.12) id PAA26766 for ; Wed, 12 Mar 1997 15:38:55 -0500 Received: from portero(192.75.23.66) by ns via smap (V1.3) id sma026473; Wed Mar 12 15:38:15 1997 Received: (from smap@localhost) by kanmaster.ca.newbridge.com (8.6.12/8.6.12) id PAA25226 for ; Wed, 12 Mar 1997 15:38:14 -0500 Received: from nova.tundra.com(138.120.102.145) by kanmaster.ca.newbridge.com via smap (V1.3) id sma025096; Wed Mar 12 15:37:03 1997 Received: from cornelius.nbmicro (cornelius.ca.newbridge.com [138.120.102.128]) by nova.tundra.com (8.6.12/8.6.12) with SMTP id PAA14417 for ; Wed, 12 Mar 1997 15:36:55 -0500 Date: Wed, 12 Mar 1997 15:36:55 -0500 From: William Prevot Message-Id: <199703122036.PAA14417@nova.tundra.com> To: ibis@vhdl.org Subject: INFO Sir, I would appreciate any information you might have on the following questions regarding the use of the Spice to Ibis conversion version 2.1: 1/In the case of an I/O model type device, when the PIN list is defined I need to specify the spice node. Do I define the input or the output node of the I/O device? Will it automatically configure itself and see the input or output node by specifying that it is an I/O device? 2/Is it possible to customize an ASCII file and implement a pullup and pulldown curve for an input buffer? (It generates only a ground and a power clamp) 3/ Is there more information on the exact implementation of the pullup and pulldown reference? Are they related to the pullup and pulldown resistances? If yes, how? 4/ I would like to characterize two different types of buffers however they are both connected to the same spice input and output nodes. They are both I/O devices. They are functionning in parallel but I would like to create a V/I response for each buffers independantly. How could I do that? Thank you for your help and time. Regards, William Prevot Tundra Semiconductor Corporation From owner-ibis Thu Mar 13 11:40:52 1997 Received: from ns.newbridge.com (ns.newbridge.com [192.75.23.67]) by vhdl.vhdl.org (8.8.5/8.8.3) with SMTP id LAA23762 for ; Thu, 13 Mar 1997 11:40:50 -0800 (PST) Received: (from smap@localhost) by ns.newbridge.com (8.6.12/8.6.12) id OAA21809 for ; Thu, 13 Mar 1997 14:38:54 -0500 Received: from portero(192.75.23.66) by ns via smap (V1.3) id sma021596; Thu Mar 13 14:38:17 1997 Received: (from smap@localhost) by kanmaster.ca.newbridge.com (8.6.12/8.6.12) id OAA13217 for ; Thu, 13 Mar 1997 14:38:15 -0500 Received: from nova.tundra.com(138.120.102.145) by kanmaster.ca.newbridge.com via smap (V1.3) id sma013005; Thu Mar 13 14:36:10 1997 Received: from cornelius.nbmicro (cornelius.ca.newbridge.com [138.120.102.128]) by nova.tundra.com (8.6.12/8.6.12) with SMTP id OAA17409 for ; Thu, 13 Mar 1997 14:36:03 -0500 Date: Thu, 13 Mar 1997 14:36:03 -0500 From: William Prevot Message-Id: <199703131936.OAA17409@nova.tundra.com> To: ibis@vhdl.org Subject: INFO Sir, I am currently setting up an ibis model of our chip based on hspice models of the different buffers. In the pin specification, they require the spice node and other parameters. For an output type, they also require the input pin which must correspond to a pin name in the list. However, all the pins on the pad are independant from one another and not connected. How is this done? Do I have to create 'dummy' pins to where input stimulus and inputs are created? Regards, William Prevot From owner-ibis Thu Mar 13 16:24:16 1997 Received: from natsemi-bh.nsc.com (natsemi-bh.nsc.com [204.163.202.66]) by vhdl.vhdl.org (8.8.5/8.8.3) with SMTP id QAA28407 for ; Thu, 13 Mar 1997 16:24:16 -0800 (PST) Received: (from uucp@localhost) by natsemi-bh.nsc.com (8.6.12/8.6.11) id QAA10740; Thu, 13 Mar 1997 16:19:41 -0800 Received: from nsc.nsc.com by natsemi-bh.nsc.com via smap (V3.1.1) id xma008996; Thu, 13 Mar 97 16:17:05 -0800 Received: from lightning-gw.nsc.com by nsc.nsc.com (5.65/1.34) with SMTP id AA14009 for ibis@vhdl.org; Thu, 13 Mar 97 16:19:13 -0800 Received: from kural by rockie.nsc.com (4.1/SMI-4.1) id AA06698; Thu, 13 Mar 97 16:21:49 PST Date: Thu, 13 Mar 97 16:21:49 PST From: huq@rockie.nsc.com (Syed Huq) Message-Id: <9703140021.AA06698@rockie.nsc.com> To: ibis@vhdl.org, wprevot@tundra.com Subject: Re: INFO William, s2ibis and s2ibis2 handle dummy pin syntax differently. For ouput for I/O pins there may be an internal spice node that is defined as input and an internal spice node defined as enable. These can be defined as 'dummy'. The exact syntax is explained by NCSU with the documentations. Regards, Syed. > > Sir, > I am currently setting up an ibis model of our chip based on hspice > models of the different buffers. In the pin specification, they require > the spice node and other parameters. For an output type, they also require > the input pin which must correspond to a pin name in the list. However, all the pins on the pad are independant from one another and not connected. > How is this done? > Do I have to create 'dummy' pins to where input stimulus and inputs are created? > Regards, > William Prevot > From owner-ibis Mon Mar 17 08:57:12 1997 Received: from ormail.intel.com (ormail.intel.com [134.134.248.3]) by vhdl.vhdl.org (8.8.5/8.8.3) with ESMTP id IAA22240 for ; Mon, 17 Mar 1997 08:57:04 -0800 (PST) Received: from ichips.intel.com (ichips.intel.com [134.134.50.200]) by ormail.intel.com (8.8.4/8.8.4) with ESMTP id IAA25665 for ; Mon, 17 Mar 1997 08:55:04 -0800 (PST) Received: from ichips.intel.com by ichips.intel.com (8.7.4/jIII) id IAA01353; Mon, 17 Mar 1997 08:46:11 -0800 (PST) Message-Id: <199703171646.IAA01353@ichips.intel.com> To: ibis@vhdl.org Subject: Series elements in Bird 36.2 Date: Mon, 17 Mar 1997 08:55:13 -0800 From: Stephen Peters Hello fellow IBISains: There has been a request to modify Bird36.2 (the electrical board description) so that the [Path Description] supports a descrete series element. I started looking at the problem this weekend and quickly realized that the existing syntax is able to support a descrete series element without modification. This is accomplished by placing two 'Node' sub-parameters back to back, each calling out a pin of the two terminal device. For an example, see below: [Path Description] Series_example Pin 5 | start Len = 2.2 L=0.5n C=2.0p / | section description Node R7.1 | pin 1 of series resistor Node R7.2 | pin 2 of series resistor Len = 0.3 L=0.5n C=2.0p / | section description Node U27.3 | end Please note that a parallel terminations to power or ground can be described using the 'terminator' type model of IBIS V2.2. I will be updating the bird to include the above example (along with some editorial comments) shortly. Thanks again for the comments. Regards, Stephen Peters Intel Corp. From owner-ibis Tue Mar 18 09:46:25 1997 Received: from mail-out1.apple.com (mail-out1.apple.com [17.254.0.52]) by vhdl.vhdl.org (8.8.5/8.8.3) with ESMTP id JAA15334 for ; Tue, 18 Mar 1997 09:46:24 -0800 (PST) Received: from scv3.apple.com (A17-128-100-121.apple.com [17.128.100.121]) by mail-out1.apple.com (8.8.5/8.8.5) with ESMTP id JAA29714 for ; Tue, 18 Mar 1997 09:42:38 -0800 Received: from pico.apple.com (pico.apple.com [17.216.20.171]) by scv3.apple.com (8.8.5/8.8.4) with SMTP id JAA03224 for ; Tue, 18 Mar 1997 09:46:29 -0800 Received: from snakeye.apple.com by pico.apple.com (4.1/SMI-4.1) id AA06969; Tue, 18 Mar 97 09:46:06 PST Received: from snakeye (localhost) by snakeye.apple.com id AA09328; Tue, 18 Mar 97 09:46:07 PST Sender: danwei@pico.apple.com Message-Id: <332ED4DE.41C67EA6@pico.apple.com> Date: Tue, 18 Mar 1997 09:46:06 -0800 From: Danwei Xue X-Mailer: Mozilla 3.01Gold (X11; I; SunOS 4.1.4 sun4m) Mime-Version: 1.0 To: ibis@vhdl.org Subject: subscribe Content-Type: multipart/mixed; boundary="------------167EB0E72781E494446B9B3D" This is a multi-part message in MIME format. --------------167EB0E72781E494446B9B3D Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Please subscribe me to this list server. Thanks. Danwei --------------167EB0E72781E494446B9B3D Content-Type: text/plain; charset=us-ascii; name="addr.txt" Content-Transfer-Encoding: 7bit Content-Disposition: inline; filename="addr.txt" ============================================= Danwei Xue, Ph.D. I/O Technologies, R & D Apple Computer, Inc. Mailing Address: MS: 60-IO Apple Computer, Inc. One Infinite Loop Cupertino, CA 95014 Location: VG-6 20705 Valley Green Drive Cupertino, CA 95014 Phone: (408)974-6869 Fax: (408)974-9775 E-mail: danwei@pico.apple.com Internet: www.apple.com ============================================= --------------167EB0E72781E494446B9B3D-- From owner-ibis Thu Mar 20 14:09:29 1997 Received: from inet1.tek.com (inet1.tek.com [134.62.48.21]) by vhdl.vhdl.org (8.8.5/8.8.3) with SMTP id OAA04045; Thu, 20 Mar 1997 14:09:23 -0800 (PST) Received: from salope.cse.tek.com by inet1.tek.com id ; Thu, 20 Mar 1997 14:06:47 -0800 Received: from salope (localhost [127.0.0.1]) by salope.cse.tek.com (8.7.5/8.7.3) with SMTP id OAA05855; Thu, 20 Mar 1997 14:06:47 -0800 (PST) Sender: brockh@mdhost.cse.tek.com Message-ID: <3331B4F7.47F3@mdhost.cse.tek.com> Date: Thu, 20 Mar 1997 14:06:47 -0800 From: Brock Hannibal X-Mailer: Mozilla 3.0 (X11; U; SunOS 5.5 sun4u) MIME-Version: 1.0 To: ibis@vhdl.org CC: awglaser@eos.ncsu.edu, ibis-users@vhdl.org, bob@icx.com Subject: s2ibis2 Content-Type: multipart/mixed; boundary="------------46BC211D71CE" This is a multi-part message in MIME format. --------------46BC211D71CE Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Hi, I've been trying to run some of the examples in the v1.1 distribution of s2ibis2. I'm using Hspice. I'm admittedly not very familiar with Hspice since we have our own internal Spice. Unfortunately converinting hspice to our internal Spice is not an option at the moment.I get the following standard output: [salope:ex2] /proj/cae/brockh/data/icx/ibis/tools/s2ibis2/bin/s2ibis2.solaris tristate.s2i s2ibis2.solaris v1.1 -- North Carolina State University s2ibis2.solaris: Reading input file tristate...done. s2ibis2.solaris: Analyzing component MCM Trisate Driver . s2ibis2.solaris: Starting HSpice job with input putout.spi. s2ibis2.solaris: Spice run (TYP) aborted. See file putout.msg for information. Curve pullup not generated. s2ibis2.solaris: Starting HSpice job with input dutout.spi. s2ibis2.solaris: Spice run (TYP) aborted. See file dutout.msg for information. Curve pullup (output disabled) not generated. Any clue as to why the pullup and pulldown curves aren't generated. I looked in the putout.spi file and it looks OK to me but I'll attach it. The file putout.msg is very short and looks like this: ^G>error ***** hspice job aborted real 7.0 user 0.5 sys 0.2 Thanks for any insight you may have. I've fiddled around quite a bit and am just not seeing the problem or oversight. -- Brock Hannibal Hardware Design Engineer Tektronix, Inc. Beaverton, Oregon "Any ideas or opinions expressed here do not necessarily reflect the ideas or opinions of my employer." --------------46BC211D71CE Content-Type: text/plain; charset=us-ascii; name="putout.spi" Content-Transfer-Encoding: 7bit Content-Disposition: inline; filename="putout.spi" * Typ pullup curve for model tristate_driver * * Spice deck created by s2ibis v 1.1 * North Carolina State University * minva vdd enable nena vdd pfet w=3.6e-06 l=6e-07 ad=2.1015e-11 as=5.4e-12 +pd=2.355e-05 ps=6.6e-06 minvb gnd enable nena gnd nfet w=1.8e-06 l=6e-07 ad=1.107e-11 as=2.7e-12 +pd=1.35e-05 ps=4.8e-06 mx33 n5 enable vdd vdd pfet w=3.84e-05 l=6e-07 ad=5.76e-11 as=5.76e-11 +pd=4.14e-05 ps=4.14e-05 mx24 n5 in n2 vdd pfet w=3.6e-06 l=6e-07 ad=2.1015e-11 as=5.4e-12 pd=2.355e-05 +ps=6.6e-06 mx25 n3 n2 n5 vdd pfet w=1.41e-05 l=6e-07 ad=2.115e-11 as=2.1015e-11 +pd=1.71e-05 ps=2.355e-05 mx27 n5 n3 n4 vdd pfet w=3.21e-05 l=6e-07 ad=9.3915e-11 as=2.889e-11 +pd=1.0125e-05 ps=1.8e-06 mx26 n4 n3 n5 vdd pfet w=3.21e-05 l=6e-07 ad=2.889e-11 as=4.815e-11 pd=1.8e-06 +ps=3.51e-05 mx32 out n4 n5 vdd pfet w=4.215e-05 l=9e-07 ad=1.0116e-10 as=7.587e-11 +pd=4.695e-05 ps=3.6e-06 mx31 n5 n4 out vdd pfet w=4.215e-05 l=9e-07 ad=7.587e-11 as=7.587e-11 +pd=3.6e-06 ps=3.6e-06 mx30 out n4 n5 vdd pfet w=4.215e-05 l=9e-07 ad=7.587e-11 as=7.587e-11 +pd=3.6e-06 ps=3.6e-06 mx29 n5 n4 out vdd pfet w=4.215e-05 l=9e-07 ad=7.587e-11 as=7.587e-11 +pd=3.6e-06 ps=3.6e-06 mx28 out n4 n5 vdd pfet w=4.215e-05 l=9e-07 ad=7.587e-11 as=9.3915e-11 +pd=3.6e-06 ps=1.0125e-05 mx14 n7 in n2 gnd nfet w=1.8e-06 l=6e-07 ad=1.107e-11 as=2.7e-12 pd=1.35e-05 +ps=4.8e-06 mx23 gnd nena n7 gnd nfet w=3.6e-05 l=6e-07 ad=5.4e-11 as=5.4e-11 pd=3.9e-05 +ps=3.9e-05 mx15 n3 n2 n7 gnd nfet w=7.2e-06 l=6e-07 ad=1.08e-11 as=1.107e-11 pd=1.02e-05 +ps=1.35e-05 mx17 n7 n3 n4 gnd nfet w=1.62e-05 l=6e-07 ad=4.725e-11 as=1.458e-11 +pd=7.575e-06 ps=1.8e-06 mx16 n4 n3 n7 gnd nfet w=1.62e-05 l=6e-07 ad=1.458e-11 as=2.43e-11 pd=1.8e-06 +ps=1.92e-05 mx22 out n4 n7 gnd nfet w=2.115e-05 l=9e-07 ad=5.076e-11 as=3.807e-11 +pd=2.595e-05 ps=3.6e-06 mx21 n7 n4 out gnd nfet w=2.115e-05 l=9e-07 ad=3.807e-11 as=3.807e-11 +pd=3.6e-06 ps=3.6e-06 mx20 out n4 n7 gnd nfet w=2.115e-05 l=9e-07 ad=3.807e-11 as=3.807e-11 +pd=3.6e-06 ps=3.6e-06 mx19 n7 n4 out gnd nfet w=2.115e-05 l=9e-07 ad=3.807e-11 as=3.807e-11 +pd=3.6e-06 ps=3.6e-06 mx18 out n4 n7 gnd nfet w=2.115e-05 l=9e-07 ad=3.807e-11 as=4.725e-11 +pd=3.6e-06 ps=7.575e-06 * N56S SPICE BSIM1 (Berkeley Level 4; HSPICE Level 13) PARAMETERS * *NMOS PARAMETERS * .MODEL nfet NMOS LEVEL=13 VFB0= +-6.67767E-01,-9.88313E-03,-3.29367E-02 + 8.60647E-01, 0.00000E+00, 0.00000E+00 + 8.17935E-01,-4.65708E-02, 4.75791E-02 + 4.25774E-02, 3.52629E-02,-2.77046E-03 +-6.14649E-05, 1.89078E-02,-1.18479E-02 + 5.83829E+02,1.40291E-001,5.07562E-001 + 3.29586E-01, 9.77520E-02,-9.32319E-02 + 1.99382E-02, 3.61973E-02,-2.86830E-03 + 1.29121E+01,-8.28086E+00, 6.90864E+00 + 7.54028E-04,-3.43366E-03, 5.18763E-04 + 2.37991E-04,-1.61033E-03,-5.39861E-03 +-6.35761E-03,-3.86200E-03, 5.33022E-03 +-5.68012E-04, 1.22523E-03, 2.85097E-04 + 6.84165E+02,-2.54285E+01, 9.21339E-01 + 4.89160E+00,-1.90933E+00, 7.94142E+00 + 4.83048E+00, 4.02423E+00,-5.33716E+00 + 7.20765E-03,-1.37194E-04,-3.70674E-03 +1.00000E-002, 2.70000E+01, 5.00000E+00 +3.63E-010,3.63E-010,4.52505E-010 +1.00000E+000,0.00000E+000,0.00000E+000 +1.00000E+000,0.00000E+000,0.00000E+000 +0.00000E+000,0.00000E+000,0.00000E+000 +0.00000E+000,0.00000E+000,0.00000E+000 * *N+ diffusion:: * +2.4, 7.732100e-04, 2.900000e-10, 1e-08, 0.8 +0.8, 1.10106, 0.26, 0, 0 * *PMOS PARAMETERS * .MODEL pfet PMOS LEVEL=13 VFB0= +-6.59693E-02,-1.78327E-02,-2.45473E-03 + 7.68179E-01, 0.00000E+00, 0.00000E+00 + 2.85648E-01,-1.64579E-02, 3.08917E-02 +-6.62532E-02, 2.49518E-02, 4.62778E-04 +-7.90844E-03, 1.92294E-02,-2.34646E-03 + 1.41704E+02,2.14000E-001,5.34406E-001 + 1.95407E-01, 6.22059E-02,-5.94668E-02 + 8.56390E-03, 1.39477E-02, 7.65802E-04 + 6.79470E+00,-1.43654E+00, 6.56475E-01 + 1.08483E-04,-1.24539E-03, 9.77240E-05 + 4.33468E-04, 1.42453E-04,-1.71650E-03 + 8.73535E-03,-1.31646E-03, 4.78072E-04 + 3.06834E-04, 4.41194E-04, 3.49198E-04 + 1.47746E+02, 1.78644E+01, 1.24739E-01 + 6.09155E+00,-1.61404E-01, 1.24507E+00 +-3.18656E-01, 2.79732E+00, 1.71058E+00 +-1.22826E-03, 1.06181E-04, 1.07711E-03 +1.00000E-002, 2.70000E+01, 5.00000E+00 +5.540E-010,5.54E-010,4.67045E-010 +1.00000E+000,0.00000E+000,0.00000E+000 +1.00000E+000,0.00000E+000,0.00000E+000 +0.00000E+000,0.00000E+000,0.00000E+000 +0.00000E+000,0.00000E+000,0.00000E+000 * *P+ diffusion:: * +2.1, 9.319100e-04, 1.563700e-10, 1e-08, 0.85 +0.85, 0.487073, 0.47848, 0, 0 * simple diode model .model clamp d vj=0.7 rs=100 VOUTS2I out 0 DC 0 VCCS2I vdd 0 DC 3.3 VGNDS2I gnd 0 DC 0 VENAS2I enable 0 DC 0 VINS2I in 0 DC 3.3 .TEMP 27 .OPTIONS INGOLD=2 .DC VOUTS2I -3.3 6.6 0.1 .PRINT DC I(VOUTS2I) .END --------------46BC211D71CE-- From owner-ibis Thu Mar 20 17:42:41 1997 Received: from natsemi-bh.nsc.com (natsemi-bh.nsc.com [204.163.202.66]) by vhdl.vhdl.org (8.8.5/8.8.3) with SMTP id RAA07799 for ; Thu, 20 Mar 1997 17:42:41 -0800 (PST) Received: (from uucp@localhost) by natsemi-bh.nsc.com (8.6.12/8.6.11) id RAA01620 for ; Thu, 20 Mar 1997 17:38:25 -0800 Received: from nsc.nsc.com by natsemi-bh.nsc.com via smap (V3.1.1) id xma029069; Thu, 20 Mar 97 17:34:51 -0800 Received: from lightning.nsc.com by nsc.nsc.com (5.65/1.34) with SMTP id AA27900 for ibis@vhdl.org; Thu, 20 Mar 97 17:37:16 -0800 Received: from kural by rockie.nsc.com (4.1/SMI-4.1) id AA02410; Thu, 20 Mar 97 17:40:01 PST Date: Thu, 20 Mar 97 17:40:01 PST From: huq@rockie.nsc.com (Syed Huq) Message-Id: <9703210140.AA02410@rockie.nsc.com> To: ibis@vhdl.org Subject: New IBIS models from National - Interface products IBIS fans, National Semiconductor has released the following Interface IBIS model. These are available from our web site at: http://www.national.com/models/ibis/interface.html 26lv31tm.ibs 3.3V RS-422 Quad Differential Driver 26lv32tm.ibs 3.3V RS-422 Quad Differential Receiver These are the DS26LV31TM and DS26LV32TM. Regards, Syed Huq National Semiconductor Corp. From owner-ibis Fri Mar 21 09:55:43 1997 Received: from inet1.tek.com (inet1.tek.com [134.62.48.21]) by vhdl.vhdl.org (8.8.5/8.8.3) with SMTP id JAA23447; Fri, 21 Mar 1997 09:55:42 -0800 (PST) Received: from salope.cse.tek.com by inet1.tek.com id ; Fri, 21 Mar 1997 09:53:14 -0800 Received: from salope (localhost [127.0.0.1]) by salope.cse.tek.com (8.7.5/8.7.3) with SMTP id JAA10810; Fri, 21 Mar 1997 09:53:03 -0800 (PST) Sender: brockh@mdhost.cse.tek.com Message-ID: <3332CAFF.45AE@mdhost.cse.tek.com> Date: Fri, 21 Mar 1997 09:53:03 -0800 From: Brock Hannibal X-Mailer: Mozilla 3.0 (X11; U; SunOS 5.5 sun4u) MIME-Version: 1.0 To: ibis@vhdl.org, awglaser@eos.ncsu.edu, ibis-users@vhdl.org, bob@icx.com Subject: Re: s2ibis2 References: <3331B4F7.47F3@mdhost.cse.tek.com> Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Thanks to all who responded to my plea for enlightenment. Once I ran hspice in stand alone mode on the deck that s2ibis2 created and kept the .lis file, I was able to understand what was happening. The problem was failure to converge due to excessive current in the nfet and pfet models at the Ibis sweep extremes(-3.3 to +6.6 volts). I reduced the sweep range and everything ran. Oh, I had to fix the "gnd" node by calling it "mygnd", still tying it to node 0 in hspice. This was for ex2 in the examples. Is there anyway to limit the automatically generated sweep range in the .s2i file? This was with hspice 96.1. Solaris. Mark Simpson wrote that the deck I attached ran fine in hspice 95.2, SunOS. Brock Hannibal wrote: > > Hi, > > I've been trying to run some of the examples in the v1.1 distribution of > s2ibis2. I'm using Hspice. > I'm admittedly not very familiar with Hspice since we have our own > internal Spice. Unfortunately converinting hspice to our internal Spice > is not an option at the moment.I get the following standard output: > > [salope:ex2] > /proj/cae/brockh/data/icx/ibis/tools/s2ibis2/bin/s2ibis2.solaris > tristate.s2i > > s2ibis2.solaris v1.1 -- North Carolina State University > s2ibis2.solaris: Reading input file tristate...done. > s2ibis2.solaris: Analyzing component MCM Trisate Driver . > s2ibis2.solaris: Starting HSpice job with input putout.spi. > s2ibis2.solaris: Spice run (TYP) aborted. See file putout.msg for > information. > Curve pullup not generated. > s2ibis2.solaris: Starting HSpice job with input dutout.spi. > s2ibis2.solaris: Spice run (TYP) aborted. See file dutout.msg for > information. > Curve pullup (output disabled) not generated. > > Any clue as to why the pullup and pulldown curves aren't generated. I > looked in the putout.spi > file and it looks OK to me but I'll attach it. The file putout.msg is > very short and looks like > this: > > ^G>error ***** hspice job aborted > > real 7.0 > user 0.5 > sys 0.2 > > Thanks for any insight you may have. I've fiddled around quite a bit and > am just not seeing the > problem or oversight. -- Brock Hannibal Hardware Design Engineer Tektronix, Inc. Beaverton, Oregon "Any ideas or opinions expressed here do not necessarily reflect the ideas or opinions of my employer." From owner-ibis Fri Mar 21 12:03:47 1997 Received: from icx.com (root@fw.icx.com [205.238.6.33]) by vhdl.vhdl.org (8.8.5/8.8.3) with SMTP id MAA25584 for ; Fri, 21 Mar 1997 12:03:45 -0800 (PST) Received: by icx.com (/\oo/\ Smail3.1.29.1 #29.2) id ; Fri, 21 Mar 97 12:01 PST Received: by icx.com (/\==/\ Smail3.1.28.1 #28.14) id ; Fri, 21 Mar 97 12:01 PST Received: by icx.com (/\==/\ Smail3.1.28.1 #28.14) id ; Fri, 21 Mar 97 12:03 PST Message-Id: Date: Fri, 21 Mar 97 12:03 PST From: bob@icx.com ( Bob Ross) To: ibis@vhdl.org Subject: IBIS Agenda 3/28/97 IBIS Open Forum Meeting Agenda for 3/28/97 Bridge Number Reservation # Passcode (916) 356-9200 2-133309 2774522 All meetings are 8:00 AM to 9:55 AM Pacific Time. When you call into the meeting, ask for the IBIS Open Forum hosted by Will Hobbs and give the Reservation Number and Passcode. 8:00 Check-In, Intros, Announcements Ross - Intros of New IBIS Participants, Meeting Quorum Ross - Membership Update and Treasurers Report Rusher - Review of Previous Meeting's Minutes (and ARs) Ross - Miscellany/Announcements All - Press & Web Page Updates Huq, All - New Models Available, Library Update Powell, All - Opens for New Issues All 8:25 Administrative and Project Discussions DAC97 IBIS Meeting Planning Rusher/Powell - Poster Powell International Progress Rusher EIAJ Meeting Report Ross, Attendees Cookbook Rokusek/Peters Accounts on EIA/IBIS Page for Source Code Destribution Rokusek/Huq FAQ Update Huq s2ibis2 Issues (& NT) Dodd New Administrative Issues All 8:50 Technical Discussion Package Committee Report Peters Nodel Description Discussion Ross BIRD36.2 - ELECTRICAL DESCRIPTIONS OF BOARDS (Vote?) Peters BIRD41.1 - MODELING SERIES SWITCHABLE DEVICES Fitzpatrick Switched Terminators Muranyi New Technical Issues All 9:50 Wrap Up and Next Meetings Plans Ross 9:55 Sign Off From owner-ibis Tue Mar 25 11:36:01 1997 Received: from mailgate.Cadence.COM (mailgate.Cadence.COM [158.140.2.1]) by vhdl.vhdl.org (8.8.5/8.8.3) with SMTP id LAA24649 for ; Tue, 25 Mar 1997 11:36:00 -0800 (PST) Received: (from smap@localhost) by mailgate.Cadence.COM (8.6.8/8.6.8) id LAA21395 for ; Tue, 25 Mar 1997 11:34:11 -0800 Received: from texas.cadence.com(158.140.152.5) by mailgate.cadence.com via smap (V1.0mjr) id sma859318450.021382; Tue Mar 25 11:34:10 1997 Received: from pc-kiritm.Cadence.COM (d158140152112.cadence.com [158.140.152.112]) by texas.Cadence.COM (8.6.8/8.6.8) with SMTP id NAA28104; Tue, 25 Mar 1997 13:35:27 -0600 Message-Id: <2.2.32.19970325193151.00675564@texas.cadence.com> X-Sender: kiritm@texas.cadence.com X-Mailer: Windows Eudora Pro Version 2.2 (32) Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Date: Tue, 25 Mar 1997 13:31:51 -0600 To: ibis@vhdl.org From: Kirit Mehta Subject: IBIS forum Cc: kiritm@texas.Cadence.COM To obtain general information about IBIS, ask specific questions for individual responses, and to inquire about joining the EIA-IBIS open forum as a full member. Hi, I want general information about IBIS and how to join EIA-IBIS open forum as a member. Thanks Kirit Mehta kiritm@cadence.com Regards, wwwww g( o 0 )g ---o00--(_)--00o--------------------------------- Kirit Mehta Consulting Engineer Cadence Design Systems, Inc. phone: (512) 349-1130 .ooo0 0ooo. fax: (512) 349-7619 ( ) ( ) email: kiritm@cadence.com -----\ (---) /------------------------------------------ \_) (_/ From owner-ibis Thu Mar 27 16:05:37 1997 Received: from relay5.UU.NET (relay5.UU.NET [192.48.96.15]) by vhdl.vhdl.org (8.8.5/8.8.3) with ESMTP id QAA12197 for ; Thu, 27 Mar 1997 16:05:37 -0800 (PST) Received: from uucp4.UU.NET by relay5.UU.NET with SMTP (peer crosschecked as: uucp4.UU.NET [192.48.96.35]) id QQcitc09842; Thu, 27 Mar 1997 19:04:03 -0500 (EST) Received: from qdt.UUCP by uucp4.UU.NET with UUCP/RMAIL ; Thu, 27 Mar 1997 19:03:46 -0500 Received: from hal.qdt.com by qdt.com (4.1/SMI-4.1) id AA02526; Thu, 27 Mar 97 15:44:33 PST Received: from f14 by hal.qdt.com (4.1/SMI-4.1) id AA21806; Thu, 27 Mar 97 15:44:34 PST Sender: jonp@qdt.com Message-Id: <333B052A.773C2448@qdt.com> Date: Thu, 27 Mar 1997 15:39:22 -0800 From: Jon Powell X-Mailer: Mozilla 3.0Gold (X11; I; SunOS 4.1.4 sun4m) Mime-Version: 1.0 To: ibis@vhdl.org Subject: Model Directory Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit The IBIS Model Directory page (accessed through the IBIS home page) has been modified with new company specific IBIS sites and a few data and web address corrections. FYI jon "the librarian" powell From owner-ibis Fri Mar 28 14:27:05 1997 Received: from crl.dec.com (crl.dec.com [192.58.206.2]) by vhdl.vhdl.org (8.8.5/8.8.3) with SMTP id OAA02242 for ; Fri, 28 Mar 1997 14:26:58 -0800 (PST) From: chu@rock.enet.dec.com Received: by crl.dec.com; id AA12468; Fri, 28 Mar 97 17:18:55 -0500 Received: by easynet.crl.dec.com; id AA04137; Fri, 28 Mar 97 17:18:27 -0500 Message-Id: <9703282218.AA04137@easynet.crl.dec.com> Received: from rock.enet; by crl.enet; Fri, 28 Mar 97 17:18:30 EST Date: Fri, 28 Mar 97 17:18:30 EST To: ibis@vhdl.org Cc: chu@rock.enet.dec.com Apparently-To: chu@rock.enet.dec.com, ibis@vhdl.org Subject: s2ibis2 Hi Everyone: I encountered some difficulties in using the latest release of the s2ibis2 Spice to IBIS conversion program from NCSU, s2ibis2 Version2 (The latest available downloaded from the IBIS web site. I am using a DEC Alpha workstation and I had to recompile to get the correct executable). The program went into execution, completed all the required .spi jobs and all the .out jobs looked ok. However, when it tried to write the .ibs file, it gave me a '9798 floating exception' error and quit. It did not gerenate the .ibs file at all (got an empty file). The 9798 number in not a constant, it changes to a new number everytime I rerun the program. There are no other error messages and I don't know where to look for the source of the error. I rerun the identical files using the older version of s2ibis2 (v0.91BETA) and it went through ok. I would appreciate any comments or suggestions anyone may have to help me resolve the problem. Thnak you Jeff Chu Digital Equipment corp. 77 Reed road Hudson, MA 01749 (508)568-4197 (508)568-5195 fax From owner-ibis Sat Mar 29 13:37:41 1997 Received: from access.mbnet.mb.ca (uucp@[204.112.178.11]) by vhdl.vhdl.org (8.8.5/8.8.3) with ESMTP id NAA23519 for ; Sat, 29 Mar 1997 13:37:40 -0800 (PST) Received: (from uucp@localhost) by access.mbnet.mb.ca (8.8.5/8.8.5) with UUCP id PAA18018; Sat, 29 Mar 1997 15:33:06 -0600 (CST) Received: by quantic.mb.ca (4.1/SMI-4.1) id AA28675; Sat, 29 Mar 97 15:34:36 CST From: ventham@quantic-emc.com (Mike Ventham) Message-Id: <9703292134.AA28675@quantic.mb.ca> Subject: Re: s2ibis2 To: chu@rock.enet.dec.com Date: Sat, 29 Mar 97 15:34:35 CST Cc: ibis@vhdl.org In-Reply-To: <9703282218.AA04137@easynet.crl.dec.com>; from "chu@rock.enet.dec.com" at Mar 28, 97 5:18 pm X-Mailer: ELM [version 2.3 PL11] > > Hi Everyone: I encountered some difficulties in using > the latest release of the s2ibis2 Spice to IBIS > conversion program from NCSU, s2ibis2 Version2 (The > latest available downloaded from the IBIS web site. I am > using a DEC Alpha workstation and I had to recompile to > get the correct executable). The program went into > execution, completed all the required .spi jobs and all > the .out jobs looked ok. However, when it tried to > write the .ibs file, it gave me a '9798 floating > exception' error and quit. It did not gerenate the .ibs > file at all (got an empty file). The 9798 number in not > a constant, it changes to a new number everytime I rerun > the program. There are no other error > messages and I don't know where to look for the source > of the error. I rerun the identical files using the > older version of s2ibis2 (v0.91BETA) and it went through > ok. I would appreciate any comments or suggestions > anyone may have to help me resolve the problem. > Jeff, The number in front of the floating exception is a process number of the process running the IBIS output. Therefore it will change everytime. The problem is the floating exception - this is usually caused by the program dividing a number by zero. The empty file is caused by the file buffer not being flushed before the program crashes. That's the diagnosis, but it is difficult to pin down the cause without using a debugger. It's sick, I don't know precisely why - hey, I should be a medical doctor! Regards Mike ________________________________________________________________ | Mike Ventham - Vice-President Engineering, | | Quantic EMC Inc Headquarters | | Croft House, Chilcompton, 191 Lombard Ave, Winnipeg, | | Somerset, UK, BA3 4JA Manitoba, Canada R3B 0X1 | | Tel: 44 (0)1761 232191 Tel: (204) 942 4000 | | Fax: 44(0)1761 233549 Fax: (204) 957 1158 | | Email: ventham@quantic-emc.com http://www.quantic-emc.com | From owner-ibis Mon Mar 31 09:05:09 1997 Received: from ormail.intel.com (ormail.intel.com [134.134.248.3]) by vhdl.vhdl.org (8.8.5/8.8.3) with ESMTP id JAA03995 for ; Mon, 31 Mar 1997 09:05:03 -0800 (PST) Received: from ichips.intel.com (ichips.intel.com [134.134.50.200]) by ormail.intel.com (8.8.4/8.8.4) with ESMTP id JAA08644 for ; Mon, 31 Mar 1997 09:02:40 -0800 (PST) Received: from ichips.intel.com by ichips.intel.com (8.7.4/jIII) id IAA26966; Mon, 31 Mar 1997 08:51:47 -0800 (PST) Message-Id: <199703311651.IAA26966@ichips.intel.com> To: ibis@vhdl.org Subject: Bird 36.3 (Electrical Board Description) Date: Mon, 31 Mar 1997 09:02:49 -0800 From: Stephen Peters Hello All: Here is the latest version of Bird 36.3, the Electical Board Description. In this update I have included an example (along with the rules for) showing how to include a series, descrete element in a [Path Description]. There have also been a few minor editoral corrections. Bareing any major modifications, this version will be be voted on at the next IBIS teleconference. Regards, Stephen Peters Intel Corp. ------------------------ cut here -------------------------------- Buffer Issue Resolution Document (BIRD) BIRD ID#: 36.3 ISSUE TITLE: Electric Descriptions of Boards REQUESTER: Stephen Peters, Hank Herrmann DATE SUBMITTED: June 23, 1996 DATE ACCEPTED BY IBIS OPEN FORUM: Pending ****************************************************************************** ****************************************************************************** STATEMENT OF THE ISSUE: There is a need to describe SIMM modules and related type components that consist of one or more ICs mounted on a PCB board that connects them to a system thru a set of pins. The following BIRD proposes a new type of file called .ebd (Electrical Board Description) that addresses this need. This proposal does not encompass an electrical description of connectors and other interconnect devices. ****************************************************************************** STATEMENT OF THE RESOLVED SPECIFICATIONS: The following text is placed in the specification after the .pkg file description and before the [End] keyword description. ==================== ELECTRICAL BOARD DESCRIPTION ==================== An Board Level Component is defined as a part that connects one or more IC packages to another part or board thru a set of user visible pins. For example, a SIMM module is an board level component in that it connects several DRAM packages to a PCB thru an edge connector. To provide a simple electrical description of the connection between the pins of the board level component and the IC packages, an electrical board description file (a .ebd file) is defined. A fundamental assumption regarding the electrical board description is that the inductance and capacitance parameters listed in the file are derived with respect to well defined reference plane(s) within the board. Also, this current description does not allow one to describe electrical (inductive or capacitive) coupling between paths. It is recommended that if coupling is an issue than an electrical description be extracted from the boards physical parameters. What is, and is not, included in an Electrical Board Description is defined by its boundaries. For the definition of the boundaries, see the Description section under the [Path Description] Keyword. Usage Rules: A .ebd file is intended to be a stand alone file, not associated with any .ibs file. Board level component descriptions are stored in a file whose name looks like .ebd, where must conform to the naming rules given in the general syntax section of this specification. The .ebd extension is mandatory. Contents: A .ebd file is structured similar to a standard IBIS file. It must contain the following keywords, as defined in the IBIS specification: [IBIS Ver], [File Name], [File Rev], and [End]. It may also contain the following optional keywords: [Comment Char], [Date], [Source], [Notes], [Disclaimer] and [Copyright]. The actual board level component description is contained between the keywords [Begin Board Description] and [End Board Description], and includes the keywords listed below. [Begin Board Description] [Manufacturer] [Number of Pins] [Pin List] [Path Description] [Reference Designator Map] [End Board Description] More than one [Begin Board Description]/[End Board Description] keyword pair is allowed in a .ebd file. |============================================================================= | Keyword: [Begin Board Description] | Required: Yes |Description: Marks the beginning of an Electrical Board Description. |Usage Rules: The keyword is followed by the name of the board level | component. If the .ebd file contains more than one [Begin | Board Description] keyword, then each name must be unique. | The length of the component name must not exceed 40 characters | in length, and blank characters are allowed. For every | [Begin Board Description] keyword there must be a | matching [End Board Description] keyword. |----------------------------------------------------------------------------- [Begin Board Description] 16Meg X 8 Simm Module | |============================================================================= | Keyword: [Manufacturer] | Required: Yes |Description: Declares the manufacturer of the part(s) that use this .ebd | file. |Usage Rules: Following the keyword is the manufacturers name. It must not | exceed 40 characters, and can include blank characters. Each | manufacturer must use a consistent name in all .ebd files. |----------------------------------------------------------------------------- [Manufacturer] Quality SIMM Corp. | |============================================================================= | Keyword: [Number of Pins] | Required: Yes |Description: Tells the parser the number of pins to expect. Pins are any | externally accessible electrical connection to the part. |Usage Rules: The field must be a positive decimal integer. | Note: The simulator must not limit the Number of Pins to any | value less than 1,000. |----------------------------------------------------------------------------- [Number of Pins] 128 | |============================================================================= | Keyword: [Pin List] | Required: Yes |Description: Tells the parser the pin names of the user accessible | pins. It also informs the parser which pins are connected to | power and ground. |Sub-params: pin_name signal_name |Usage Rules: Following the [Pin List] keyword are two columns. The first | column lists the pin name while the second lists the data book | name of the signal connected to that pin. There must be as many | pin_name/signal_name rows as there are pins given by the | preceding [Number of Pins] keyword. Pin names must be the | alphanumeric external pin names of the part. The pin | names cannot exceed eight characters in length. Any pin | associated with a signal name that begins with "GND" or | "POWER" will be interpreted as connecting to the boards ground | or power plane. In addition, NC is a legal signal name and | indicates that the Pin is a 'no connect'. As per the IBIS | standard "GND", "POWER" and "NC" are case insensitive. | |----------------------------------------------------------------------------- | A SIMM BOARD EXAMPLE | [Pin List] pin_name signal_name A1 GND A2 data1 A3 data2 A4 POWER5 | this pin connects to 5v A5 NC | a no connect pin | . | . A22 POWER3.3 | this pin connects to 3.3v B1 casa | . | . |etc. | |============================================================================ | Keyword: [Path Description] | Required: Yes |Description: This keyword allows the user to describe the connection | between the user accessible pins of a part and the pins of | the ICs mounted on that part. Each pin to node connection is | divided into one or more cascaded "sections", where each | section is described in terms of it's L/R/C per unit length. | The Fork and Endfork subparameters allow the path to branch | to multiple nodes, or another pin. A path description is | required for each pin whose signal name is not "GND", "POWER" | or "NC". | | BOARD DESCRIPTION AND IC BOUNDARIES: | In any system, each part interfaces with another part at some | boundary. Every part model must contain the components | necessary to represent the behavior of the part being modeled | within its boundaries. The boundary definition depends upon | the parts being represented by the model. | | For CARD EDGE CONNECTIONS such as a SIMM or a PC Daughter | Card plugged into a SIMM Socket or Edge Connector, the | boundary should be at the end of the board card edge pads as | they emerge from the connector. | | For any THROUGH-HOLE MOUNTED PART, the boundary will be at | the surface of the board on which the part is mounted. | | SURFACE MOUNTED PART models end at the outboard end of their | recommended surface mount pads. | | If the board level component contains an UNMATED CONNECTOR, | the unmated connector will be described in a separate file, | with it's boundaries being as described above for the | through-hole or surface mounted part. | | Sub-params: Len, L, R, C, Fork, Endfork, Pin, Node |Usage Rules: Each individual connection path (user pin to node(s)) | description begins with the | [Path Description] keyword and a path name, followed by the | subparameters used to describe the path topology and the | electrical characteristics of each section of the path. The | path name must not exceed 40 characters, blanks are not allowed, | and each occurrence of the [Path Description] keyword must be | followed by a unique path name. Every signal pin (pins other | than POWER, GND or NC) must appear in one and only one path | description per [Begin Board Description]/[End Board | Description] pair. Pin names do not have to appear in the | same order as listed in the [Pin List] table. The individual | subparameters are broken up into those that describe the | electrical properties of a section, and those that describe | the topology of a path. | | SECTION DESCRIPTION SUBPARAMETERS: | The Len, L, R, and C subparameters specify the length, the | series inductance and resistance and the capacitance to ground | of each section in a path description. | Len The physical length of a section. Lengths are given | in terms of arbitrary 'units'. Any non-zero length | requires that the parameters that follow must be | interpreted as distributed elements by the simulator. | L The series inductance of a section, in terms of | 'inductance/unit length'. For example, if the total | inductance of a section is 3.0 nH and the length of the | section is 2 'units', the inductance would be listed | as L = 1.5 nH (i.e. 3.0 / 2). | C The capacitance to ground of a section, in terms of | capacitance per unit length. | R The series DC (ohmic) resistance of a section, in | terms of ohms per unit length. | | TOPOLOGY DESCRIPTION SUBPARAMETERS: | The Fork and Endfork subparameters denote branches from the | main pin-to-node or pin-to-pin connection path. The Node | subparameter is used to reference the pin of a component | or board as defined in a .ibs or .edb file. The Pin | subparameter is used to indicate the point at which a path | connects to a user visible pin. | Fork This subparameter indicates that the sections | following (up to the Endfork subparameter) are part | of a branch off of the main connection path. This | subparameter has no arguments. | Endfork This subparameter indicates the end point of a | branch. For every Fork subparameter there must be a | corresponding Endfork subparameter. As with the Fork | subparameter, the Endfork subparameter has no arguments. | Node reference_designator.pin | This subparameter is used when the connection path | connects to a pin of another, externally defined part. | The arguments of the Node subparameter indicate the pin | and reference designator of the external component. The | pin and reference designator portions of the argument are | separated by a period ("."). The reference designator is | mapped to an external component description (another .ebd | file or .ibs file) by the [Reference Designator Map] | Keyword. Note that a Node MUST reference a model of | a passive or active component. A Node is not an | arbitrary connection point between two elements or | paths. | Pin This subparameter is used to mark the point at which | a path description connects to a user accessible pin. | Every path description must contain at least one | occurrence of the Pin subparameter. It may also contain | the reserved word NC. The value of the Pin subparameter | must be one of the pin names listed in the [Pin List] | section. | | Using The Subparameters to Describe Paths: | A section description begins with the Len subparameter and | ends with the slash (/) character. The value of the Len, L, | R and C subparameters and the subparameter itself are separated | by an equals sign (=); whitespace around the equals sign is | optional. The Fork, Endfork, Node and Pin subparameters are | placed between section descriptions (i.e. between the concluding | slash of one section and the 'Len' parameters that starts | another). The arguments of the Pin and Node subparameter are | separated by white space. | | Specifying a Len or L/R/C value of zero is allowed. If | Len = 0 is specified, then the L/R/C values are the total | for that section. If a non-zero length is specified, then | the total L/R/C for a section is calculated by multiplying | the value of the Len subparameter by the value of the L, | R or C subparameter. However, as noted below, if a non- | zero length is specified, that section MUST be interpreted as | distributed elements. | | Legal Subparameter Combinations for Section Descriptions: | | A) Len, and one or more of the L, R and C subparameters. If | the Len subparameter is given as zero, then the L/R/C sub- | parameters represent lumped elements. If the Len subparameter | is non-zero, then the L/R/C subparameters represent distributed | elements and both L and C must be specified, R is optional. | | B) The first subparameter following the [Path Description] | keyword must be 'Pin', followed by one or more section | descriptions. The path description can terminate in a Node, | another pin or the reserved word, NC. | | Dealing With Series Elements | A discrete series R or L component can be included in a path | description by defining a section with L=0 and the proper | R or L value. A discrete series component can also be | included in a path description by writing two back to back | node statements that reference the same component (see the | example below). Note that both ends of a discrete, two | terminal component MUST be contained in a single [Path | Description]. Connecting two seperate [Path Description] | with a series component is not allowed. | |--------------------------------------------------------------------------- | | | AN EXAMPLE PATH FOR A SIMM MODULE | [Path Description] CAS_2 Pin J25 Len = 0.5 L=8.35n C=3.34p R=0.01 / Node u21.15 Len = 0.5 L=8.35n C=3.34p R=0.01 / Node u22.15 Len = 0.5 L=8.35n C=3.34p R=0.01 / Node u23.15 | | A DESCRIPTION USING THE FORK AND ENDFORK SUBPARAMETERS | [Path Description] PassThru1 Pin B5 Len = 0 L=2.0n / Len = 2.1 L=6.0n C=2.0p / Fork Len = 1.0 L = 1.0n C= 2.0p / Node u23.15 Endfork Len = 1.0 L = 6.0n C=2.0p / Pin A5 | | A DESCRIPTION INCLUDING A DISCRETE SERIES ELEMENT | [Path Description] sig1 Pin B27 Len = 0 L=1.6n / Len = 1.5 L=6.0n C=2.0p / Node R2.1 Node R2.2 Len = 0.25 L=6.0n C=2.0p / Node U25.6 | |============================================================================= | Keyword: [Reference Designator Map] | Required: Yes, if any of the path descriptions use the Node subparameter. |Description: Maps a reference designator to a component or electrical | board description contained in an .ibs or .edb file. |Usage Rules: The [Reference Designator Map] keyword must be followed by a | list of all of the reference designators called out by the Node | subparameters used in the various path descriptions. Each | reference designator is followed by the name of the .ibs or | .ebd file containing the electrical description of the | component or board, then the name of the component itself as | given by the .ibs or .ebd file's [Component] or [Begin Board | Description] keyword respectively. The reference designator, | file name and component name terms are separated by whitespace. | By default the .ibs or .ebd files are assumed to exist in the | same directory as the calling .edb file. It is legal for a | reference designator to point to a component that is | contained in the calling .ebd file. |----------------------------------------------------------------------------- [Reference Designator Map] | | EXTERNAL PART REFERENCES | |Ref Des File name Component name u23 pp100.ibs Pentium(R)__Pro_Processor u24 simm.ebd 16Meg X 36 SIMM Module u25 ls244.ibs National 74LS244a u26 r10K.ibs My_10K_Pullup | |============================================================================= | Keyword: [End Electrical Description] | Required: Yes |Description: Marks the end of an Electrical Interconnect Description. |Usage Rules: This keyword must come at the end of each complete electrical | interconnect model description. | | Optionally, a comment may be added after the [End Electrical | Description] keyword to clarify which board model has | ended. |----------------------------------------------------------------------------- [End Electrical Description] | End: 16Meg X 8 Simm Module | ****************************************************************************** ANALYSIS PATH/DATA THAT LED TO SPECIFICATION: From owner-ibis Mon Mar 31 14:55:56 1997 Received: from bhole.cae.ca (cae.ca [142.39.200.50]) by vhdl.vhdl.org (8.8.5/8.8.3) with SMTP id OAA10328 for ; Mon, 31 Mar 1997 14:55:54 -0800 (PST) Received: from rome.cae.ca by poster.cae.ca (AIX 3.2/UCB 5.64/4.03) id AA61906; Mon, 31 Mar 1997 17:51:57 -0500 Received: from pcq63.cae.ca by rome.cae.ca (SMI-8.6/SMI-SVR4) id RAA13314; Mon, 31 Mar 1997 17:47:10 -0500 Message-Id: <33403F99.3D94@cae.ca> Date: Mon, 31 Mar 1997 17:50:01 -0500 From: "Real Mongrain Jr." Organization: CAE Electronics Ltd, Montreal, Canada X-Mailer: Mozilla 3.0 (Win95; I) Mime-Version: 1.0 To: ibis@vhdl.org Subject: mult. voltage in S2IBIS2 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Hi, I would like to translate a GTL SPICE model using S2IBIS2. My problem is that this device need a supply of 3.3v, 5v and a Vref of 0.8v. This mean that i have to supply 3 different voltage values. How can i specify 3 different voltage sources? Regards, Real. -- =============================================================== Real Mongrain Jr. MailTo:mongrain@cae.ca CAE Electronics Ltd http://www.cae.ca 8585 Cote de Liesse St-Laurent, Qc, Canada, H4T 1G6 Tel.:(514) 341-6780 ext.3218 fax.:(514) 734-5618 =============================================================== From owner-ibis Mon Mar 31 15:13:26 1997 Received: from dragon.ti.com (dragon.ti.com [192.94.94.61]) by vhdl.vhdl.org (8.8.5/8.8.3) with ESMTP id PAA10691 for ; Mon, 31 Mar 1997 15:13:25 -0800 (PST) Received: from happy.memh.ti.com ([158.218.36.100]) by dragon.ti.com (8.8.5) with ESMTP id RAA16815 for ; Mon, 31 Mar 1997 17:11:01 -0600 (CST) Received: from phoenix.memh.ti.com by happy.memh.ti.com with ESMTP (1.37.109.16/16.2) id AA061039860; Mon, 31 Mar 1997 17:11:01 -0600 From: Jackson Leung Received: by phoenix.memh.ti.com id ; Mon, 31 Mar 1997 17:11:00 -0600 Message-Id: <199703312311.AA182209860@phoenix.memh.ti.com> Subject: IBIS to SPICE To: ibis@vhdl.org Date: Mon, 31 Mar 1997 17:11:00 -0600 (CST) X-Mailer: ELM [version 2.4 PL24] Mime-Version: 1.0 Content-Type: text/plain; charset=US-ASCII Content-Transfer-Encoding: 7bit Hi, I am brand new in this discussion group and thus please bear with my "dumb" questions: How can I can run SPICE with IBIS models? Is there an IBIS to SPICE translator available or an example showing how to find eqv. SPICE model(s) from an IBIS model? Thanks in advance. -- Best Regards, . =///// . .JACKSON LEUNG, (281) 274-3175 \o.o/ TEXAS INSTRUMENTS. .---------------------------------.ooO---(_)---Ooo.-----------------. .http://www.wp.com/Jackson_Leung jleung@ti.com HOUSTON, TEXAS. .-------------------------------------------Oooo.-------------------. . .oooO ( ) . . ( ) ) / . . \ ( (_/ . . \_) .