From dmccal@teleport.com  Mon Oct  2 22:49:53 1995
Return-Path: <dmccal@teleport.com>
Received: from desiree.teleport.com by vhdl.vhdl.org (4.1/SMI-4.1/BARRNet)
	id AA20157; Mon, 2 Oct 95 22:49:53 PDT
Received: from ip-pdx02-14.teleport.com (ip-pdx02-14.teleport.com [204.119.60.78]) by desiree.teleport.com (8.6.12/8.6.9) with SMTP id WAA26174 for <ibis@vhdl.org>; Mon, 2 Oct 1995 22:42:41 -0700
Date: Mon, 2 Oct 1995 22:42:41 -0700
Message-Id: <199510030542.WAA26174@desiree.teleport.com>
X-Sender: dmccal@mail.teleport.com
Mime-Version: 1.0
Content-Type: text/plain; charset="us-ascii"
To: ibis@vhdl.org
From: dmccal@teleport.com (Dennis McCal)
Subject: unsubscribe
X-Mailer: <PC Eudora Version 1.4>

unsubscribe


From Arpad_Muranyi@ccm.fm.intel.com  Tue Oct  3 08:33:36 1995
Return-Path: <Arpad_Muranyi@ccm.fm.intel.com>
Received: from ormail.intel.com by vhdl.vhdl.org (4.1/SMI-4.1/BARRNet)
	id AA28646; Tue, 3 Oct 95 08:33:36 PDT
Received: from relay.jf.intel.com by ormail.intel.com with smtp
	(Smail3.1.28.1 #7) id m0t09Eh-000UiQC; Tue, 3 Oct 95 08:26 PDT
Received: from ccm.hf.intel.com by relay.jf.intel.com
	(Smail3.1.28.1 #2) id m0t09Ef-000twkC; Tue, 3 Oct 95 08:26 PDT
Received: by ccm.hf.intel.com (ccmgate 3.2 #3) Tue, 03 Oct 95 08:26:25 PDT
Date: Tue, 03 Oct 95 08:17:00 PDT
From: Arpad Muranyi <Arpad_Muranyi@ccm.fm.intel.com>
Message-Id: <Tue, 03 Oct 95 08:26:18 PDT_2@ccm.hf.intel.com>
To: ibis@vhdl.org
Subject: BIRD30.1

BIRD ID#:      30.1
ISSUE TITLE:   Programmable buffers in IBIS models
REQUESTOR:     Arpad Muranyi

DATE SUBMITTED:                       10-03-95
DATE ACCEPTED BY IBIS OPEN FORUM:     Pending

******************************************************************************
******************************************************************************

STATEMENT OF THE ISSUE:

The current IBIS specification (2.1) does not provide a selection mechanism
for buffers which can change characteristics based on configuration options in
a component (programmable buffers).  This BIRD is being written to provide a
solution to this problem.  Using this feature of the IBIS models simulator
tools can implement a mode selection user interface for programmable buffers.

******************************************************************************

STATEMENT OF THE RESOLVED SPECIFICATIONS:

A new keyword shall be introduced in the IBIS specification to provide a user
friendly buffer mode selection mechanism for components which use programmable
buffers.  The proposed keyword [Model selector] shall have a unique model
selector name on its right with the same syntax rules which apply to the model
name used with the [Model] keyword.

The model selector name is used in the [Pin] list in place of the buffer name
for pins which have programmable buffers.  Under the [Model selector] keyword
a list of those model names should appear which can be used by the pin
referencing this model selector name.  The first entry in the list is
considered to be the default [Model].  To help the user of the simulator tool
to make an intelligent choice, a single word description must appear on the
right of each of the model names in this list.

==============================================================================
|     Keyword:  [Model selector] 
|    Required:  No.
| Description:  Used to pick a [Model] from a list of [Model]s for a pin which 
|               uses a programmable buffer.
|  Sub-Params:  None.
| Usage Rules:  A programmable buffer must have an individual [Model] section
|               for each one of its modes used in the .ibs file.  The names of
|               these [Models] must be unique and can be listed under the
|               [Model selector] keyword and/or pin list.  The name of the
|               [Model selector] keyword must match the corresponding model
|               name listed under the [Pin] keyword and must not contain more
|               than 20 characters.  A .ibs file must contain enough [Model
|               selector] keywords to cover all of the model selector names
|               specified under the [Pin] keyword.
|
|               The section under the [Model selector] keyword must have two
|               columns.  The two columns must be separated by at least one
|               space or tab character.  However, the use of tab characters is
|               not recommended in general.  The first column lists the
|               [Model] names.  The second column contains a single word 
|               description of the [Model] in the first column.  The contents
|               and format of this description is not standardized, however it
|               shall be limited in length so that none of the descriptions
|               exceed the 80-character length of the line that it started on.
|               The purpose of the descriptions is to aid the user of the
|               simulator tool in making intelligent buffer mode selections
|               and it can be used by the simulator tool in a user interface
|               dialog box as the bases of an interactive buffer selection
|               mechanism.
|
|               The first entry under the [Model selector] keyword shall be
|               considered the default by the simulator tool for all those
|               pins which call this [Model selector].
|
|               The operation of this selection mechanism implies that a group
|               of pins which use the same programmable buffer (i.e. model
|               selector name) will be switched together from one [Model] to
|               another.  Therefore, if two groups of pins, for example an
|               address bus and a data bus, use the same programmable buffer,
|               the user must have the capability to configure them
|               independently.  One can use two [Model selector] keywords with
|               unique names and the same list of [Model] keywords; however,
|               the usage of the [Model selector] is not limited to these
|               examples.  Many other combinations are possible.
|
|
[Pin]   signal_name     model_name      R_pin   L_pin   C_pin
|
  1     RAS0#           Progbuffer1     200.0m  5.0nH   2.0pF
  2     EN1#            Input1          NA      6.3nH   NA
  3     A0              3-state
  4     D0              Progbuffer2
  5     D1              Progbuffer2     320.0m  3.1nH   2.2pF
  6     D2              Progbuffer2
  7     RD#             Input2          310.0m  3.0nH   2.0pF
|  .
|  .
|  .
  18     Vcc3            POWER
| 
|
[Model selector]        Progbuffer1
|
ABCD0123456789ABCDE0 2 mA buffer, without slew rate control
ABCD0123456789ABCDE1 4 mA buffer, without slew rate control
ABCD0123456789ABCDE2 6 mA buffer, without slew rate control
ABCD0123456789ABCDE3 4 mA buffer, with slew rate control
ABCD0123456789ABCDE4 6 mA buffer, with slew rate control
|
[Model selector]        Progbuffer2
|
ABCD0123456789ABCDE0 2 mA buffer, without slew rate control
ABCD0123456789ABCDE3 16 mA buffer, without slew rate control
ABCD0123456789ABCDE4 6 mA buffer, with slew rate control
ABCD0123456789ABCDE5 8 mA buffer, with slew rate control
ABCD0123456789ABCDE6 10 mA buffer, with slew rate control
******************************************************************************

ANALYSIS PATH/DATA THAT LED TO SPECIFICATION:

Problem statement

Some components have programmable I/O buffers which can be configured for
different operating modes.  Their strength or slew rate (and maybe other
characteristics) can be changed during operation by some mechanism.  Currently,
the IBIS buffer modeling syntax provides keywords to describe a buffer model
in only one configuration or mode.  Even though there are ways to work around
this problem in the present form of IBIS, there is a definite need to provide
an easier and more user friendly selection mechanism for the various
configuration modes of programmable buffers.

Possible solutions

(1)  Currently it is NOT illegal to have more [Model] keywords in the IBIS
models than what the pin list section calls for.  Therefore, the writer of an
IBIS model can make as many [Model] sections as many are needed to describe
the various modes of the programmable buffers.  The user of the IBIS model can
change the model names of the programmable buffers in the [Pin] list section
with a text editor to select the desired buffer mode.  Instructions about
these edits can be placed in the Notes section and/or behind the comment
character for the user.  The main problem with this method is that it requires
tedious manual editing of the IBIS file.

(2)  A slightly different solution would use the same amount of [Model]
sections as described above, but repeat each pin description in the [Pin] list
as many times as many configurations a buffer associated with that pin has.
This method is not allowed in the current IBIS specification, but could be
made to work if the repeated pin descriptions are preceded with a comment
character.  This way the user could uncomment the line(s) which contain the
model name with the desired buffer mode.  This editing is much less tedious
and error prone than the one described in (1) above, but it can be cumbersome.
If the repeated pin description was legal in IBIS without the use of the
comment characters, the simulation tool could pick up the various model
choices from the [Pin] list section and provide a dialog box showing a list of
the available buffer modes for that pin.  The main problem with this method is
that the pin list can grow very long due to the repetitions.

(3)  Use #Define syntax to compile the IBIS model beforehand with the proper
buffers based on a model with multiple choices.  There are various C tools
that can do this.  One issue is if models can be changed dynamically such as
might be done to optimize a driver for a certain net.  This method has the
advantage that it does not require a new keyword, therefore it can be used
immediately.  However, it requires an extra compilation step before the IBIS
model can be used.  This contradicts one of the main goals of the IBIS
specification which was to provide simulation tools with models which can be
used directly.  This method could be used as an interim solution until the
new keywords are defined in the next IBIS revision.

(4)  A similar method to the one described in the STATEMENT OF THE RESOLVED
SPECIFICATIONS section would introduce a new keyword or sub parameter to be
used under the [Model] keyword.  This means that a [Model] could have many
complete sets of I-V and V-t curves which describe the various operating modes
of the buffer.  For example, one set of keywords describing a buffer in one
mode could come after the sub-parameter called [mode1], the next set of
keywords describing the buffer in another mode could reside under the
sub-parameter called [mode2], and so on, till all of the modes of the buffer
are characterized.  The default buffer could be defined with another
sub-parameter, such as Default.  The only difference between this method and
the suggested one in the main section of this document is that the selection
mechanism is inside the [Model] keyword and not outside.  However, this minor
difference imposes some limitations and might make an IBIS file unnecessarily
larger.

******************************************************************************

ANY OTHER BACKGROUND INFORMATION:

Based on the IBIS Open Forum discussions, two slight modifications were made to
the original BIRD issued as BIRD30.  One of the changes was the removal of the
sub-parameter Default and making the first entry in the [Model] list the
default.  The other change was the addition of a second column which contains
a description for each [Model] to be used in the user interface of the
simulation tools.  The original BIRD30 became BIRD30.1 with these changes.

******************************************************************************


From Arpad_Muranyi@ccm.fm.intel.com  Tue Oct  3 16:52:14 1995
Return-Path: <Arpad_Muranyi@ccm.fm.intel.com>
Received: from ormail.intel.com by vhdl.vhdl.org (4.1/SMI-4.1/BARRNet)
	id AA02479; Tue, 3 Oct 95 16:52:14 PDT
Received: from relay.jf.intel.com by ormail.intel.com with smtp
	(Smail3.1.28.1 #7) id m0t0H1F-000Ul2C; Tue, 3 Oct 95 16:45 PDT
Received: from ccm.hf.intel.com by relay.jf.intel.com
	(Smail3.1.28.1 #2) id m0t0H1E-000txdC; Tue, 3 Oct 95 16:45 PDT
Received: by ccm.hf.intel.com (ccmgate 3.2 #3) Tue, 03 Oct 95 16:45:04 PDT
Date: Tue, 03 Oct 95 16:42:00 PDT
From: Arpad Muranyi <Arpad_Muranyi@ccm.fm.intel.com>
Message-Id: <Tue, 03 Oct 95 16:45:03 PDT_1@ccm.hf.intel.com>
To: ibis@vhdl.org
Subject: BIRD30.1 again

Hi folks,

I was in a hurry when I prepared BIRD30.1 and I forgot to fix up the 
examples.  So please ignore the previous EMAIL I sent with BIRD30.1 and 
replace it with this one.  I hope I got it right this time.

Thanks,

Arpad Muranyi
Intel Corporation
========================================================================
BIRD ID#:      30.1
ISSUE TITLE:   Programmable buffers in IBIS models
REQUESTOR:     Arpad Muranyi

DATE SUBMITTED:                       10-03-95
DATE ACCEPTED BY IBIS OPEN FORUM:     Pending

******************************************************************************
******************************************************************************

STATEMENT OF THE ISSUE:

The current IBIS specification (2.1) does not provide a selection mechanism
for buffers which can change characteristics based on configuration options in
a component (programmable buffers).  This BIRD is being written to provide a
solution to this problem.  Using this feature of the IBIS models simulator
tools can implement a mode selection user interface for programmable buffers.

******************************************************************************

STATEMENT OF THE RESOLVED SPECIFICATIONS:

A new keyword shall be introduced in the IBIS specification to provide a user
friendly buffer mode selection mechanism for components which use programmable
buffers.  The proposed keyword [Model selector] shall have a unique model
selector name on its right with the same syntax rules which apply to the model
name used with the [Model] keyword.

The model selector name is used in the [Pin] list in place of the buffer name
for pins which have programmable buffers.  Under the [Model selector] keyword
a list of those model names should appear which can be used by the pin
referencing this model selector name.  The first entry in the list is
considered to be the default [Model].  To help the user of the simulator tool
to make an intelligent choice, a single word description must appear on the
right of each of the model names in this list.

==============================================================================
|     Keyword:  [Model selector] 
|    Required:  No.
| Description:  Used to pick a [Model] from a list of [Model]s for a pin which 
|               uses a programmable buffer.
|  Sub-Params:  None.
| Usage Rules:  A programmable buffer must have an individual [Model] section
|               for each one of its modes used in the .ibs file.  The names of
|               these [Models] must be unique and can be listed under the
|               [Model selector] keyword and/or pin list.  The name of the
|               [Model selector] keyword must match the corresponding model
|               name listed under the [Pin] keyword and must not contain more
|               than 20 characters.  A .ibs file must contain enough [Model
|               selector] keywords to cover all of the model selector names
|               specified under the [Pin] keyword.
|
|               The section under the [Model selector] keyword must have two
|               columns.  The two columns must be separated by at least one
|               space or tab character.  However, the use of tab characters is
|               not recommended in general.  The first column lists the
|               [Model] names.  The second column contains a single word 
|               description of the [Model] in the first column.  The contents
|               and format of this description is not standardized, however it
|               shall be limited in length so that none of the descriptions
|               exceed the 80-character length of the line that it started on.
|               The purpose of the descriptions is to aid the user of the
|               simulator tool in making intelligent buffer mode selections
|               and it can be used by the simulator tool in a user interface
|               dialog box as the bases of an interactive buffer selection
|               mechanism.
|
|               The first entry under the [Model selector] keyword shall be
|               considered the default by the simulator tool for all those
|               pins which call this [Model selector].
|
|               The operation of this selection mechanism implies that a group
|               of pins which use the same programmable buffer (i.e. model
|               selector name) will be switched together from one [Model] to
|               another.  Therefore, if two groups of pins, for example an
|               address bus and a data bus, use the same programmable buffer,
|               the user must have the capability to configure them
|               independently.  One can use two [Model selector] keywords with
|               unique names and the same list of [Model] keywords; however,
|               the usage of the [Model selector] is not limited to these
|               examples.  Many other combinations are possible.
|
|
[Pin]   signal_name     model_name      R_pin   L_pin   C_pin
|
  1     RAS0#           Progbuffer1     200.0m  5.0nH   2.0pF
  2     EN1#            Input1          NA      6.3nH   NA
  3     A0              3-state
  4     D0              Progbuffer2
  5     D1              Progbuffer2     320.0m  3.1nH   2.2pF
  6     D2              Progbuffer2
  7     RD#             Input2          310.0m  3.0nH   2.0pF
|  .
|  .
|  .
  18     Vcc3            POWER
| 
|
[Model selector]        Progbuffer1
|
ABCD0123456789ABCDE0 2_mA_buffer__without_slew_rate_control
ABCD0123456789ABCDE1 4_mA_buffer__without_slew_rate_control
ABCD0123456789ABCDE2 6_mA_buffer__without_slew_rate_control
ABCD0123456789ABCDE3 4_mA_buffer__with_slew_rate_control
ABCD0123456789ABCDE4 6_mA_buffer__with_slew_rate_control
|
[Model selector]        Progbuffer2
|
ABCD0123456789ABCDE0 2_mA_buffer__without_slew_rate_control
ABCD0123456789ABCDE3 16_mA_buffer__without_slew_rate_control
ABCD0123456789ABCDE4 6_mA_buffer__with_slew_rate_control
ABCD0123456789ABCDE5 8_mA_buffer__with_slew_rate_control
ABCD0123456789ABCDE6 10_mA_buffer__with_slew_rate_control
******************************************************************************

ANALYSIS PATH/DATA THAT LED TO SPECIFICATION:

Problem statement

Some components have programmable I/O buffers which can be configured for
different operating modes.  Their strength or slew rate (and maybe other
characteristics) can be changed during operation by some mechanism.  Currently,
the IBIS buffer modeling syntax provides keywords to describe a buffer model
in only one configuration or mode.  Even though there are ways to work around
this problem in the present form of IBIS, there is a definite need to provide
an easier and more user friendly selection mechanism for the various
configuration modes of programmable buffers.

Possible solutions

(1)  Currently it is NOT illegal to have more [Model] keywords in the IBIS
models than what the pin list section calls for.  Therefore, the writer of an
IBIS model can make as many [Model] sections as many are needed to describe
the various modes of the programmable buffers.  The user of the IBIS model can
change the model names of the programmable buffers in the [Pin] list section
with a text editor to select the desired buffer mode.  Instructions about
these edits can be placed in the Notes section and/or behind the comment
character for the user.  The main problem with this method is that it requires
tedious manual editing of the IBIS file.

(2)  A slightly different solution would use the same amount of [Model]
sections as described above, but repeat each pin description in the [Pin] list
as many times as many configurations a buffer associated with that pin has.
This method is not allowed in the current IBIS specification, but could be
made to work if the repeated pin descriptions are preceded with a comment
character.  This way the user could uncomment the line(s) which contain the
model name with the desired buffer mode.  This editing is much less tedious
and error prone than the one described in (1) above, but it can be cumbersome.
If the repeated pin description was legal in IBIS without the use of the
comment characters, the simulation tool could pick up the various model
choices from the [Pin] list section and provide a dialog box showing a list of
the available buffer modes for that pin.  The main problem with this method is
that the pin list can grow very long due to the repetitions.

(3)  Use #Define syntax to compile the IBIS model beforehand with the proper
buffers based on a model with multiple choices.  There are various C tools
that can do this.  One issue is if models can be changed dynamically such as
might be done to optimize a driver for a certain net.  This method has the
advantage that it does not require a new keyword, therefore it can be used
immediately.  However, it requires an extra compilation step before the IBIS
model can be used.  This contradicts one of the main goals of the IBIS
specification which was to provide simulation tools with models which can be
used directly.  This method could be used as an interim solution until the
new keywords are defined in the next IBIS revision.

(4)  A similar method to the one described in the STATEMENT OF THE RESOLVED
SPECIFICATIONS section would introduce a new keyword or sub parameter to be
used under the [Model] keyword.  This means that a [Model] could have many
complete sets of I-V and V-t curves which describe the various operating modes
of the buffer.  For example, one set of keywords describing a buffer in one
mode could come after the sub-parameter called [mode1], the next set of
keywords describing the buffer in another mode could reside under the
sub-parameter called [mode2], and so on, till all of the modes of the buffer
are characterized.  The default buffer could be defined with another
sub-parameter, such as Default.  The only difference between this method and
the suggested one in the main section of this document is that the selection
mechanism is inside the [Model] keyword and not outside.  However, this minor
difference imposes some limitations and might make an IBIS file unnecessarily
larger.

******************************************************************************

ANY OTHER BACKGROUND INFORMATION:

Based on the IBIS Open Forum discussions, two slight modifications were made to
the original BIRD issued as BIRD30.  One of the changes was the removal of the
sub-parameter Default and making the first entry in the [Model] list the
default.  The other change was the addition of a second column which contains
a description for each [Model] to be used in the user interface of the
simulation tools.  The original BIRD30 became BIRD30.1 with these changes.

******************************************************************************

From harish.patel@tempe.vlsi.com  Thu Oct  5 09:57:11 1995
Return-Path: <harish.patel@tempe.vlsi.com>
Received: from relayhost.vlsi.com (tweety.vlsi.com) by vhdl.vhdl.org (4.1/SMI-4.1/BARRNet)
	id AA02956; Thu, 5 Oct 95 09:57:11 PDT
Received: from relayhost.tempe.vlsi.com ([134.27.128.1]) by relayhost.vlsi.com (8.6.12/Hub-Perlotto/050895) with ESMTP id KAA06510 for <ibis@vhdl.org>; Thu, 5 Oct 1995 10:12:07 -0700
From: harish.patel@tempe.vlsi.com
Received: from pcdmail.tempe.vlsi.com (hole.tempe.vlsi.com [134.27.130.2]) by relayhost.tempe.vlsi.com (8.6.9/Hub-Perlotto/032095) with ESMTP id JAA00074 for <ibis@vhdl.org>; Thu, 5 Oct 1995 09:56:42 -0700
Received: from mardi.tempe.vlsi.com (mardi.tempe.vlsi.com [134.27.133.22]) by pcdmail.tempe.vlsi.com (8.6.9/Hub-Perlotto/032095) with SMTP id JAA27137 for <ibis@vhdl.org>; Thu, 5 Oct 1995 09:54:42 -0700
Received: by mardi.tempe.vlsi.com id AA07138; Thu, 5 Oct 95 09:49:57 MST
Date: Thu, 5 Oct 95 09:49:57 MST
Message-Id: <9510051649.AA07138@mardi.tempe.vlsi.com>
To: ibis@vhdl.org
Subject: subscription

I would like to added on eamil list for ibis subscription.


---------------------------------------------------------
Harish Patel          Design Engineer
VLSI Technology, Inc.
8375 South River Parkway, M/S 265, Tempe, AZ 85284
Hello:(602)752-6202       Fax:(602)752-6002
Email: harish.patel@tempe.vlsi.com
---------------------------------------------------------

From bob@icx.com  Fri Oct  6 15:01:24 1995
Return-Path: <bob@icx.com>
Received: from icx.com (icx.rain.com) by vhdl.vhdl.org (4.1/SMI-4.1/BARRNet)
	id AA16685; Fri, 6 Oct 95 15:01:24 PDT
Received: by icx.com (/\==/\ Smail3.1.28.1 #28.14)
	id <m0t1KgS-000FVXC@icx.com>; Fri, 6 Oct 95 14:52 PDT
Received: by icx.com (/\==/\ Smail3.1.28.1 #28.14)
	id <m0t1Kj2-000GjSC@icx.com>; Fri, 6 Oct 95 14:54 PDT
Message-Id: <m0t1Kj2-000GjSC@icx.com>
Date: Fri, 6 Oct 95 14:54 PDT
From: bob@icx.com ( Bob Ross)
To: 73053.721@compuserve.com, 75123.3477@compuserve.com, ibis@vhdl.org,
        jonp@qdt.com, will_hobbs@ccm2.jf.intel.com
Subject: IBISCHK2 Release

Will, Jon, Paul, Ron

I just checked ibischk2 (version 10) for the [Package] keyword omission
problem on a DOS and UNIX machine, and problem is fixed.  So the "(Beta)"
designation can be removed and ibischk2 executables can be created for
public distribution on vhdl.org.  

Bob Ross,
Interconnectix, Inc.

From Will_Hobbs@ccm.jf.intel.com  Fri Oct  6 16:27:51 1995
Return-Path: <Will_Hobbs@ccm.jf.intel.com>
Received: from ormail.intel.com by vhdl.vhdl.org (4.1/SMI-4.1/BARRNet)
	id AA17258; Fri, 6 Oct 95 16:27:51 PDT
Received: from relay.jf.intel.com by ormail.intel.com with smtp
	(Smail3.1.28.1 #7) id m0t1M45-000UgDC; Fri, 6 Oct 95 16:20 PDT
Received: from ccm.jf.intel.com by relay.jf.intel.com
	(Smail3.1.28.1 #2) id m0t1M43-000txHC; Fri, 6 Oct 95 16:20 PDT
Received: by ccm.jf.intel.com (ccmgate 3.2 #3) Fri, 06 Oct 95 16:20:27 PDT
Date: Fri, 06 Oct 95 16:17:00 PDT
From: Will Hobbs <Will_Hobbs@ccm.jf.intel.com>
Message-Id: <Fri, 06 Oct 95 16:20:24 PDT_3@ccm.jf.intel.com>
To: bob@icx.com, 73053.721@compuserve.com, 75123.3477@compuserve.com,
        ibis@vhdl.org, jonp@qdt.com, will_hobbs@ccm2.jf.intel.com
Subject: Re: IBISCHK2 Release


Text item: 

Jon should have received it by now, too. Jon, please do a quick sanity check to 
make sure it's OK, and we'll pull the trigger on the final release.

Will

Will, Jon, Paul, Ron

I just checked ibischk2 (version 10) for the [Package] keyword omission 
problem on a DOS and UNIX machine, and problem is fixed.  So the "(Beta)" 
designation can be removed and ibischk2 executables can be created for 
public distribution on vhdl.org.

Bob Ross,
Interconnectix, Inc.

Text item: External Message Header

The following mail header is for administrative use
and may be ignored unless there are problems.

***IF THERE ARE PROBLEMS SAVE THESE HEADERS***.

Subject: IBISCHK2 Release
To: 73053.721@compuserve.com, 75123.3477@compuserve.com, ibis@vhdl.org,
        jonp@qdt.com, will_hobbs@ccm2.jf.intel.com
From: bob@icx.com ( Bob Ross)
Date: Fri, 6 Oct 95 14:54 PDT
Message-Id: <m0t1Kj2-000GjSC@icx.com>
Received: by icx.com (/\==/\ Smail3.1.28.1 #28.14)
     id <m0t1Kj2-000GjSC@icx.com>; Fri, 6 Oct 95 14:54 PDT
Received: by icx.com (/\==/\ Smail3.1.28.1 #28.14)
     id <m0t1KgS-000FVXC@icx.com>; Fri, 6 Oct 95 14:52 PDT
Received: from icx.com (icx.rain.com) by vhdl.vhdl.org (4.1/SMI-4.1/BARRNet)
     id AA16685; Fri, 6 Oct 95 15:01:24 PDT
Received: from vhdl.vhdl.org by hermes.intel.com (5.65/10.0i); Fri, 6 Oct 95 15:
35:09 -0700
Received: from hermes.intel.com by ichips.intel.com (5.64+/10.0i); Fri, 6 Oct 95
 15:35:25 -0700
Received: from ichips.intel.com by relay.jf.intel.com with smtp
     (Smail3.1.28.1 #2) id m0t1LMW-000txPC; Fri, 6 Oct 95 15:35 PDT

From bob@icx.com  Wed Oct 11 10:34:58 1995
Return-Path: <bob@icx.com>
Received: from icx.com (icx.rain.com) by vhdl.vhdl.org (4.1/SMI-4.1/BARRNet)
	id AA19211; Wed, 11 Oct 95 10:34:58 PDT
Received: by icx.com (/\==/\ Smail3.1.28.1 #28.14)
	id <m0t34wB-000FVWC@icx.com>; Wed, 11 Oct 95 10:27 PDT
Received: by icx.com (/\==/\ Smail3.1.28.1 #28.14)
	id <m0t34yk-000GjSC@icx.com>; Wed, 11 Oct 95 10:30 PDT
Message-Id: <m0t34yk-000GjSC@icx.com>
Date: Wed, 11 Oct 95 10:30 PDT
From: bob@icx.com ( Bob Ross)
To: ibis@vhdl.org
Subject: IBIS MINUTES 10/6/95

 DATE:    October 11, 1995
 
 SUBJECT: 10/06/95 EIA IBIS Open Forum Meeting Minutes
 
 VOTING MEMBERS:
 AT&T Global Info Solutions     Dave Moxley*
 Cadence Design                 Sandeep Khanna, C. Kumar*
 Contec CAE, Ltd.               Dileep Divekar*
 HyperLynx                      Kellee Crisafulli
 IBM                            Jay Diepenbrock
 INCASES                        Werner Rissiek, Olaf Rethmeier
 Intel Corporation              Stephen Peters*, Will Hobbs*, Arpad Muranyi*,
                                Derrick Duehren
 Interconnectix, Inc.           Bob Ross*
 Meta-Software                  Les Spruiell, Mei Wong, You-Pang Wei, 
                                John Sliney
 Motorola                       Ron Werner
 National Semiconductor         Syed Huq*, Atul Agarwal, Cheng-Yang Kao
 NEC                            Hiroshi Matsumoto, Eldar Yazbashevz
 Quad Design                    Jon Powell, Chris Myles*
 Quantic Labs                   Mike Ventham
 Tanner Research, Inc.          Scott Wedge, Ed Miller, Peter Parrish
 Texas Instruments              Roger Cline, Ben Andresen
 Thomson-CSF/SCTF               Jean LeBrun
 UniCAD Canada Ltd.             Stephen Lum
 VLSI Technology                Dick Ulmer*, Sung Oh*
 Zuken-Redac                    John Berrie
 
 OTHER PARTICIPANTS:
 ARPA                           Randy Harr
 Anacad                         Steffen Rochel
 Ansoft                         Henri Maramis
 Atmel Corporation              Dan Terry
 Cadlab                         Ralf Bruning
 CFI                            Ron Christopher*
 Digital Equipment Corp.        Barry Katz
 EIA                            Patti Rusher
 High Design Technology         Michael Smith, Dr. Ing. Cosso
 Hewlett Packard                Tom Langdorf, Karl Kachigan, Henry Wu
 Integrated Silicon Systems     Eric Bracken
 Intergraph                     Ian Dodd, David Wiens, Walter Katz
 IntuSoft                       Charles Hymowitz
 LSI Logic Corp.                Satish Pratadneni
 Mentor Graphics                Ravender Goyal, Greg Doyle
 Micron Technology              Brian Johnson                       
 MicroSim                       Arthur Wong
 North Carolina State U.        Steve Lipa, Michael Steer
 OptEM Engineering, Inc.        Benny Leveille, Ken Ehn
 Pacific Numerix                Paul K. U. Wang
 Symmetry                       Martin Walker
 Synopsys, Logic Modeling G.    Bill Lattin
 Univ. of Illinois, Urbana      Raj Mittra 
 Zeelan Technology              George Opsahl, Hiro Moriyasu
 (Independent)                  Bob Ward

 In the list above, attendees at the meeting are indicated by *.
 
 Upcoming Meetings: The bridge numbers for future IBIS teleconferences are as 
 follows:
      Date       Bridge Number    Reservation #    Passcode 
      10/27/95   (916) 356-9200   1-29704          4532338
      11/17/95   (916) 356-9200   1-29707          9376211

 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
 None.

 
 EIA MEMBERSHIP AND TREASURER'S REPORT
 The treasury is still about $8725.54.  


 MINUTES REPORT, MISC.
 Some spelling corrections have been made.  Will reviewed the AR's.


 MISCELLANY/ANNOUNCEMENTS
 None.


 PRESS UPDATES
 Electronic Design (September 18, 1995), pp. 69-83 with a major contribution
 by Jon Powell on IBIS.

 EE Times Reference to IBIS in a Roadmap Discussion around Sept, 1995.


 NEW MODELS
 National has submitted a new cbtl model and revised the super_I/O model.
 Intel has some i960 Processor models for possible submission.


 OPENS FOR NEW ISSUES
 None.


 EIA IBIS RATIFICATION
 Will Hobbs indicated that the process toward ratification has been slower than
 expected, but that all needed material has been submitted.  So the package
 should be forwarded to EDEC shortly for a 10 day review period.  EIA-656
 should be official by the end of October.

 There was no discussion on press release, but one should be forthcoming
 from EIA upon ratification of EIA-656.


 WEB UPDATE (AND EIA)
 Syed Huq sent all of the material to EIA and it is in shape for activation
 of the home page.  There is a legal or administrative hold up, which needs
 to be resolved.

 AR - Syed Huq contact Patti Rusher regarding obstacles and report back
 to the mailing list.

 The EDN article figures still need conversion.  One figure can be 
 recreated by Syed.

 AR - Stephen Peters and Arpad Muranyi locate the original figure or
 locate a new one to give to Syed.


 FACE TO FACE MEETING
 National Semiconductor voluteered to host the face-to-face meeting in
 Santa Clara in January, 1996.  Syed Huq is investigating dates on 
 either side of the SuperCon96 meeting scheduled around the end of
 January, 1996.  

 AR - Syed Huq report the proposed dates.


 MODEL USAGE TRACKING
 Syed Huq needs closure on the model usage tracking on vhdl.org.  Previously
 Steve Lipa had indicated that it should not be difficult to set up.

 AR - Syed Huq contact Steve Lipa and Michael Steer regarding setting up
 the model usage tracking system. and give status of model usage tracking
 project.


 GOLDEN PARSER UPDATE
 A bug producing a "BUG" versus the correct "ERROR" message has been 
 discovered in the Beta 9 release (and earlier versions) when [Package]
 is omitted entirely.  The corrections is minor, so a small test version
 is being distributed to validate the fix.  Upon approval, the final
 release will be put on vhdl.org.  Bob Ross reported that the ibischk2
 directory is in place.

 Another difference has been recently discovered.  IBIS Version 1.1 
 supports multiple [Disclaimer] keywords, but when the files are designated
 Version 2.1, an error is reported.  This impacts attaching the generic
 IBIS disclaimer along with the disclaimer within the model.  The work
 around is to put the "|" in front of the IBIS disclaimer or to eliminate
 the second keyword entirely.  It was decided not to fix this problem
 at this time (causing further delay), but to wait until a possible 
 future correction release if other probems are found.

 Once the corrected ibischk2 is checked, the process to post it will
 be done through Jon Powell to make the executables, and Bob Ross to
 put them on vhdl.org per AR's of the last meeting.

 AR - Bob Ross post a note when ibischk2 version 10 is checked. [Done]


 SPICE TO IBIS VERSION 2.1
 Michael Steer and North Carolina State University team have posted a Beta
 correction version on vhdl.org under /pub/ibis/s2ibis/s2ibis_v2.091 to 
 use other than global node 0 for ground.  Node 0 causes problems with
 some Spices.


 COOKBOOK
 Bob Ross reported no progress.


 BIRD27.1(2) DEFAULT DIFFERENTIAL THRESHOLD
 Bob Ross introduced BIRD27.2, a revision to the original proposal by Bob Ward.
 The revised bird which offers some syntax efficiencies for differential pin
 designation was discussed.  This BIRD does not provide any technical change.
 The effiencies would cause the parser to be even more complicated.
 
 BIRD27.2 was Voted Down by Membership vote for Version 3.0.

 It could be reopened in the future prior to Version 3.0 if there is
 renewed interest or need.


 BIRD28.3  PACKAGE MODEL ENHANCEMENT
 Stephen Peters introduced BIRD28.3 with a clarification to use Maxwell
 Capacitances for the [Capacitance Matrix] and a forward slash notational
 correction.    Some clarifying technical discussion occurred related to
 length of stubs, mutual coupling, SSO, and MCM migration paths.  Stephen
 also reported that he presented the approach to JEDEC JC-15, a subcommittee
 concerned with packaging, and they generally approved of the approach 
 which allows taking coupling into account.

 BIRD28.3 was Approved by Membership Vote.


 PHYSICAL PACKAGE DISCUSSION
 Ron Christopher raised the question about the relationship of BIRD28.3
 to MCM packages and whether there was a migration path.  In general, this
 BIRD did not intend to address MCMs, but is positioned as an accuracy 
 extension to the existing package model.   

 C. Kumar indicated that geometrical descriptions require field solvers
 and other equipment to solve this problem.  (This is actually the business
 area of several simulator companies involved with IBIS.)  Ron mentioned
 that EDIF Version 4 0 0 representation may offer a solution to the geometric
 representation.  The EDIF committee has a reflector, and perhaps we should
 link up with them and discuss how to handle the MCM representation.  Ron
 also mentioned that there are other related standards.

 AR - Ron Christopher check into linking up with EDIF on this issue.

 AR - Ron Christopher post to the reflector information on DIE, DIET, DCL, 
 and EDIF PCB MCM.


 BIRD30 - PIN PROGRAMMABLE BUFFER STRENGTHS
 Arpad Muranyi discussed BIRD30.1 which has the "default" sub-parameter
 removed and the discription reduced to one word.  Stephen Peters preferred
 limiting the description to text of 60 characters with internal white spaces 
 for easier reading.  Bob Ross prefers one word for syntactical consistency,
 but this is not a strong point.
 
 AR - Arpad Muranyi submit BIRD30.2 with internal white space inclusion.


 CFI/OVI TELECONFERENCE
 Ron Christopher raised the concern that timing standards need to track
 pin programmable buffers.  This spawned a discussion on back-annotation,
 static timing efforts by CFI, OVI, and Vital.  

 CFI/OVI has a teleconference scheduled for 11 AM PCT on October 12, and
 they would like to have IBIS members participate to discuss system level
 timing and delay calculation.  The number is 201-839-5184 and mention
 Ellis Cohen Conference Call.


 NEXT MEETING:
 It is set on Friday, October 27, 1995, chaired by Jon Powell in Will's
 absense 

 ==============================================================================
                                       NOTES
 
 IBIS CHAIR: Will Hobbs (503) 264-4369, Fax (503) 264-4210
             will_hobbs@ccm.jf.intel.com
             Modeling Manager, Intel Corp.
             2111 NE 28th M/S JF1-57, Hillsboro, OR 97124 USA
 
 VICE CHAIR: Jon Powell (805) 988-8250, Fax: (805) 988-8259
             jonp@qdt.com
             1385 Del Norte Rd., Camarillo, CA 93010
 
 SECRETARY:  Bob Ross (503) 603-2523, fax (503) 639-3469
             bob@icx.com
             10220 SW Nimbus Ave, K4, Portland, OR 97223
 
 To become a voting member of the EIA IBIS Open Forum, send email to 
 ibis-info@vhdl.org for instructions.
 
 If you want to join the e-mail reflector (ibis@vhdl.org), send e-mail to the 
 IBIS secretary at ibis-request@vhdl.org.
 
 Check the pub/ibis directory on vhdl.org for more information on previous 
 discussions and results.  You can get on via ftp anonymous, "guest" login from 
 telnet or dial-in (415-335-0110), or send an email request to the automatic 
 archive server, archive@vhdl.org.
 
 "IBIS Spoken Here" placards are available from Jon Powell (jonp@qdt.com) for 
 use at trade shows.
 ==============================================================================
 



From speters@ichips.intel.com  Wed Oct 11 16:01:27 1995
Return-Path: <speters@ichips.intel.com>
Received: from hermes.intel.com by vhdl.vhdl.org (4.1/SMI-4.1/BARRNet)
	id AA20676; Wed, 11 Oct 95 16:01:27 PDT
Received: from ichips.intel.com by hermes.intel.com (5.65/10.0i); Wed, 11 Oct 95 15:52:47 -0700
Received: from xtg801 by ichips.intel.com (5.64+/10.0i); Wed, 11 Oct 95 15:52:37 -0700
Received: from localhost by xtg801.intel.com (4.1/10.0i); Wed, 11 Oct 95 15:52:36 PDT
Message-Id: <9510112252.AA14562@xtg801.intel.com>
To: dla@pyramid.com, si-list@silab.Eng.Sun.COM, ibis@vhdl.org
Cc: Arpad_Muranyi@ccm.fm.intel.com
Subject: Re: Model availability for DOS Hspice..
Date: Wed, 11 Oct 1995 15:52:35 -0700
From: Stephen Peters <speters@ichips.intel.com>


Hello Don, Arpad:

     Im curious, what needs/requirements drive you to use SPICE models?
Can the vendor supply you with IBIS models instead? (Not that I'm biased towards
IBIS or anything <grin>.)

            Regards,
            Stephen Peters
            Intel Corp (and member of the IBIS open forum)



----------------------
Text item: 

Don,

Most of the models I have ran across were written with level 3, 13 or 28 MOSFET 
models.  The bigger issue in my mind is whether the vendors will give you 
(usable) transistor level models at all...

Just now, I am working with several vendors (3) on some models, and so far, none
of them are running.  I found syntax errors, which I don't know how to correct 
(not because I don't know HSPICE, but because I don't know what is in the chip);
I received netlists without process files, and similar issues which caused lots 
of phone calls, waiting, and headaches...  I have to admit, one of them came 
with level 37, but that was also written in a company proprietary SPICE 
language, which I could not get to give me correct results on HSPICE yet, not 
even on the worksation version.

Some of your questions could be best answered by Meta Software, I would suggest 
to give them a call.

Good luck...

Arpad Muranyi
Intel Corporation
==============================================================================
Hello!

Perhaps you folks could give me some information.

I am reading from the HSPICE User's Manual 1995 Volume 2 "Elements and
Models", page 6-2. It says that the PC (DOS-based) version of Hspice
has built-in support for MOSFET model levels 1 - 8, 13, and 28.

The Unix version supports MOSFET model levels 1 - 15, 17 - 28, and 30 - 39.

My use for Hspice is simple transmission line analysis using an actual
spice model instead of a behavioral model. I am using a plethora of
Signal Integrity (SI) tools to supplement my work.

My question is, can I get the models I need from vendors for the PC version?

I bought the PC-version of Hspice for the following reasons:

(1) Cheaper

The software is $5K and so is a fast Pentium PC with 32M of RAM. Total
solution cost is ~$10K. The Unix version is ~$21K and a Sparc5 (32M of
memory) is ~$7.5K. Total solution cost is $28.5K. (I think the PC is
even faster than the SparcStation).

(2) I forget

I don't want to hold up this e-mail while I try to remember the other
reason (just another example of why you should write in outline
(brain-dump) form first and wordsmith it later). :)

The sales literature, form 73302/4.95/1M, mentions very little about
proprietary model support, and nothing about the PC version supporting
less than the Unix version.

Do I have to spend more money, (i.e. get the Unix version), to get
the model support? And if the answer is "yes", should I go ahead and
take a closer look at some of the other more full-featured signal
integrity tools?

Any and all input and suggestions will be appreciated.


Thank you
     Don Abernathey

Text item: External Message Header

The following mail header is for administrative use
and may be ignored unless there are problems.

***IF THERE ARE PROBLEMS SAVE THESE HEADERS***.

Content-Type: text/plain; charset=us-ascii
Mime-Version: 1.0
Cc: dla@pyrodactyl.or.pyramid.com
Subject: Model availability for DOS Hspice..
To: si-list@silab.Eng.Sun.COM
X-Mailer: Z-Mail (3.2.0 06sep94)
Date: Wed, 11 Oct 1995 12:04:15 -0700
Message-Id: <9510111204.ZM17811@pyrodactyl.or.pyramid.com>
From: "Don Abernathey" <dla@pyramid.com>
Received: by pyrodactyl.or.pyramid.com (5.67/Pyramid_Internal_Configuration)
     id AA17813; Wed, 11 Oct 95 19:04:16 GMT
Received: from pyrodactyl.or.pyramid.com
     by gossip.pyramid.com (5.61/OSx5.1a Pyramid-Internet-Gateway)
     id AA27229; Wed, 11 Oct 95 12:04:19 -0700
Received: from gossip.pyramid.com by mercury.Sun.COM (Sun.COM)
     id MAA06982; Wed, 11 Oct 1995 12:04:22 -0700
Received: from mercury.Sun.COM (mercury.EBay.Sun.COM) by Eng.Sun.COM (5.x/SMI-5.
3)
     id AA08751; Wed, 11 Oct 1995 12:04:23 -0700
Received: from Eng.Sun.COM (engmail1) by silab.Eng.Sun.COM (4.1/SMI-4.1)
     id AA03453; Wed, 11 Oct 95 12:04:41 PDT
Received: from silab.Eng.Sun.COM (silab-188.Eng.Sun.COM) by Eng.Sun.COM (5.x/SMI
-5.3)
     id AA23045; Wed, 11 Oct 1995 12:08:08 -0700
Received: from Eng.Sun.COM by mercury.Sun.COM (Sun.COM)
     id MAA08119; Wed, 11 Oct 1995 12:08:26 -0700
Received: from mercury.Sun.COM by aurora.intel.com (5.65/10.0i); Wed, 11 Oct 95
12:25:51 -0700
Received: from aurora.intel.com by fmmail.fm.intel.com with smtp
     (Smail3.1.28.1 #2) id m0t36lM-000rJpC; Wed, 11 Oct 95 12:24 PDT

From Arpad_Muranyi@ccm.fm.intel.com  Wed Oct 11 16:27:22 1995
Return-Path: <Arpad_Muranyi@ccm.fm.intel.com>
Received: from marceau.fm.intel.com by vhdl.vhdl.org (4.1/SMI-4.1/BARRNet)
	id AA20746; Wed, 11 Oct 95 16:27:22 PDT
Received: from fmmail.fm.intel.com by marceau.fm.intel.com (5.65/10.0i); Wed, 11 Oct 95 16:18:44 -0700
Received: from ccm.fm.intel.com by fmmail.fm.intel.com
	(Smail3.1.28.1 #2) id m0t3AOT-000rHfC; Wed, 11 Oct 95 16:17 PDT
Received: by ccm.fm.intel.com (ccmgate 3.0) Wed, 11 Oct 95 16:17:01 PST
Date: Wed, 11 Oct 95 16:17:01 PST
From: Arpad Muranyi <Arpad_Muranyi@ccm.fm.intel.com>
Message-Id: <951011161701_1@ccm.fm.intel.com>
To: speters@ichips.intel.com, dla@pyramid.com, si-list@silab.Eng.Sun.COM,
        ibis@vhdl.org
Subject: Re[2]: Model availability for DOS Hspice..


Text item: 

Many times that is the only thing we can get because the vendor doesn't support 
or make IBIS models yet.  I wish they would make IBIS models, though.  I would 
not have to convert them then.

Arpad

=============================================================================

Hello Don, Arpad:

     Im curious, what needs/requirements drive you to use SPICE models?
Can the vendor supply you with IBIS models instead? (Not that I'm
biased towards
IBIS or anything <grin>.)

            Regards,
            Stephen Peters
            Intel Corp (and member of the IBIS open forum)



----------------------

Text item: 

Don,

Most of the models I have ran across were written with level 3, 13
or 28 MOSFET
models.  The bigger issue in my mind is whether the vendors will give you
(usable) transistor level models at all...

Just now, I am working with several vendors (3) on some models, and
so far, none
of them are running.  I found syntax errors, which I don't know how
to correct
(not because I don't know HSPICE, but because I don't know what is
in the chip);
I received netlists without process files, and similar issues which
caused lots
of phone calls, waiting, and headaches...  I have to admit, one of them came
with level 37, but that was also written in a company proprietary SPICE
language, which I could not get to give me correct results on HSPICE yet, not
even on the worksation version.

Some of your questions could be best answered by Meta Software, I
would suggest
to give them a call.

Good luck...

Arpad Muranyi
Intel Corporation
==============================================================================
Hello!

Perhaps you folks could give me some information.

I am reading from the HSPICE User's Manual 1995 Volume 2 "Elements and
Models", page 6-2. It says that the PC (DOS-based) version of Hspice
has built-in support for MOSFET model levels 1 - 8, 13, and 28.

The Unix version supports MOSFET model levels 1 - 15, 17 - 28, and 30 - 39.

My use for Hspice is simple transmission line analysis using an actual
spice model instead of a behavioral model. I am using a plethora of
Signal Integrity (SI) tools to supplement my work.

My question is, can I get the models I need from vendors for the PC version?

I bought the PC-version of Hspice for the following reasons:

(1) Cheaper

The software is $5K and so is a fast Pentium PC with 32M of RAM. Total
solution cost is ~$10K. The Unix version is ~$21K and a Sparc5 (32M of
memory) is ~$7.5K. Total solution cost is $28.5K. (I think the PC is
even faster than the SparcStation).

(2) I forget

I don't want to hold up this e-mail while I try to remember the other
reason (just another example of why you should write in outline
(brain-dump) form first and wordsmith it later). :)

The sales literature, form 73302/4.95/1M, mentions very little about
proprietary model support, and nothing about the PC version supporting
less than the Unix version.

Do I have to spend more money, (i.e. get the Unix version), to get
the model support? And if the answer is "yes", should I go ahead and
take a closer look at some of the other more full-featured signal
integrity tools?

Any and all input and suggestions will be appreciated.


Thank you
     Don Abernathey

Text item: External Message Header

The following mail header is for administrative use
and may be ignored unless there are problems.

***IF THERE ARE PROBLEMS SAVE THESE HEADERS***.

Content-Type: text/plain; charset=us-ascii
Mime-Version: 1.0
Cc: dla@pyrodactyl.or.pyramid.com
Subject: Model availability for DOS Hspice..
To: si-list@silab.Eng.Sun.COM
X-Mailer: Z-Mail (3.2.0 06sep94)
Date: Wed, 11 Oct 1995 12:04:15 -0700
Message-Id: <9510111204.ZM17811@pyrodactyl.or.pyramid.com>
From: "Don Abernathey" <dla@pyramid.com>
Received: by pyrodactyl.or.pyramid.com (5.67/Pyramid_Internal_Configuration)
     id AA17813; Wed, 11 Oct 95 19:04:16 GMT
Received: from pyrodactyl.or.pyramid.com
     by gossip.pyramid.com (5.61/OSx5.1a Pyramid-Internet-Gateway)
     id AA27229; Wed, 11 Oct 95 12:04:19 -0700
Received: from gossip.pyramid.com by mercury.Sun.COM (Sun.COM)
     id MAA06982; Wed, 11 Oct 1995 12:04:22 -0700
Received: from mercury.Sun.COM (mercury.EBay.Sun.COM) by Eng.Sun.COM
(5.x/SMI-5.
3)
     id AA08751; Wed, 11 Oct 1995 12:04:23 -0700
Received: from Eng.Sun.COM (engmail1) by silab.Eng.Sun.COM (4.1/SMI-4.1)
     id AA03453; Wed, 11 Oct 95 12:04:41 PDT
Received: from silab.Eng.Sun.COM (silab-188.Eng.Sun.COM) by Eng.Sun.COM
(5.x/SMI
-5.3)
     id AA23045; Wed, 11 Oct 1995 12:08:08 -0700
Received: from Eng.Sun.COM by mercury.Sun.COM (Sun.COM)
     id MAA08119; Wed, 11 Oct 1995 12:08:26 -0700
Received: from mercury.Sun.COM by aurora.intel.com (5.65/10.0i); Wed,
11 Oct 95
12:25:51 -0700
Received: from aurora.intel.com by fmmail.fm.intel.com with smtp
     (Smail3.1.28.1 #2) id m0t36lM-000rJpC; Wed, 11 Oct 95 12:24 PDT

Text item: External Message Header

The following mail header is for administrative use
and may be ignored unless there are problems.

***IF THERE ARE PROBLEMS SAVE THESE HEADERS***.

From: Stephen Peters <speters@ichips.intel.com>
Date: Wed, 11 Oct 1995 15:52:35 -0700
Subject: Re: Model availability for DOS Hspice..
Cc: Arpad_Muranyi@ccm.fm.intel.com
To: dla@pyramid.com, si-list@silab.Eng.Sun.COM, ibis@vhdl.org
Message-Id: <9510112252.AA14562@xtg801.intel.com>
Received: from localhost by xtg801.intel.com (4.1/10.0i); Wed, 11 Oct 95 15:52:3
6 PDT
Received: from xtg801 by ichips.intel.com (5.64+/10.0i); Wed, 11 Oct 95 15:52:37
 -0700
Received: from ichips.intel.com by hermes.intel.com (5.65/10.0i); Wed, 11 Oct 95
 15:52:47 -0700
Received: from hermes.intel.com by fmmail.fm.intel.com with smtp
     (Smail3.1.28.1 #2) id m0t3A14-000rHfC; Wed, 11 Oct 95 15:52 PDT

From dfogelx@ichips.intel.com  Wed Oct 11 20:49:27 1995
Return-Path: <dfogelx@ichips.intel.com>
Received: from hermes.intel.com by vhdl.vhdl.org (4.1/SMI-4.1/BARRNet)
	id AA21701; Wed, 11 Oct 95 20:49:27 PDT
Received: from ichips.intel.com by hermes.intel.com (5.65/10.0i); Wed, 11 Oct 95 20:42:12 -0700
Received: from pdx841 by ichips.intel.com (5.64+/10.0i); Wed, 11 Oct 95 20:42:06 -0700
Received: by pdx841.intel.com (4.1/10.0i); Wed, 11 Oct 95 20:42:06 PDT
Message-Id: <9510120342.AA21492@pdx841.intel.com>
Subject: Re: Re[2]: Model availability for DOS Hspice..
To: Arpad_Muranyi@ccm.fm.intel.com (Arpad Muranyi)
Date: Wed, 11 Oct 1995 20:42:05 -0700 (PDT)
From: "David Fogel" <dfogelx@ichips.intel.com>
Cc: ibis@vhdl.org, speters@ichips.intel.com, dla@pyramid.com,
        si-list@silab.Eng.Sun.COM
In-Reply-To: <951011161701_1@ccm.fm.intel.com> from "Arpad Muranyi" at Oct 11, 95 04:17:01 pm
X-Mailer: ELM [version 2.4 PL22]
Mime-Version: 1.0
Content-Type: text/plain; charset=US-ASCII
Content-Transfer-Encoding: 7bit
Content-Length: 7162      

Hello Arpad and Stephen,
The availability of IBIS models greatly depends on the number of times your device
vendor was requested to supply I/O models, and IBIS models in particular.
Most of the vendors supply those models as a service to their customers and would like
to put as little effort as possible into it. It is much easier for them to dig the
Spice deck for a device's I/O buffer from an engineer's drawer than to assign 
an engineer to generate the IBIS model.
The IBIS concept is fairly new to many IC vendors and too often I see IBIS models
that are incorrect or simply don't have sufficient data in them.
If the vendor is knowledgeable about IBIS in general and understand what you are asking
for, then I ususally request (and also get) the model in IBIS format. Otherwise, I
prefer to get the Spice deck and generate the model (IBIS or vendor specific) by 
myself. However, as you already know, thing are changing very rapidly in our industry
and expect more and more vendors to supply correct IBIS models as times goes by.

David Fogel


> 
> 
> Text item: 
> 
> Many times that is the only thing we can get because the vendor doesn't support 
> or make IBIS models yet.  I wish they would make IBIS models, though.  I would 
> not have to convert them then.
> 
> Arpad
> 
> =============================================================================
> 
> Hello Don, Arpad:
> 
>      Im curious, what needs/requirements drive you to use SPICE models?
> Can the vendor supply you with IBIS models instead? (Not that I'm
> biased towards
> IBIS or anything <grin>.)
> 
>             Regards,
>             Stephen Peters
>             Intel Corp (and member of the IBIS open forum)
> 
> 
> 
> ----------------------
> 
> Text item: 
> 
> Don,
> 
> Most of the models I have ran across were written with level 3, 13
> or 28 MOSFET
> models.  The bigger issue in my mind is whether the vendors will give you
> (usable) transistor level models at all...
> 
> Just now, I am working with several vendors (3) on some models, and
> so far, none
> of them are running.  I found syntax errors, which I don't know how
> to correct
> (not because I don't know HSPICE, but because I don't know what is
> in the chip);
> I received netlists without process files, and similar issues which
> caused lots
> of phone calls, waiting, and headaches...  I have to admit, one of them came
> with level 37, but that was also written in a company proprietary SPICE
> language, which I could not get to give me correct results on HSPICE yet, not
> even on the worksation version.
> 
> Some of your questions could be best answered by Meta Software, I
> would suggest
> to give them a call.
> 
> Good luck...
> 
> Arpad Muranyi
> Intel Corporation
> ==============================================================================
> Hello!
> 
> Perhaps you folks could give me some information.
> 
> I am reading from the HSPICE User's Manual 1995 Volume 2 "Elements and
> Models", page 6-2. It says that the PC (DOS-based) version of Hspice
> has built-in support for MOSFET model levels 1 - 8, 13, and 28.
> 
> The Unix version supports MOSFET model levels 1 - 15, 17 - 28, and 30 - 39.
> 
> My use for Hspice is simple transmission line analysis using an actual
> spice model instead of a behavioral model. I am using a plethora of
> Signal Integrity (SI) tools to supplement my work.
> 
> My question is, can I get the models I need from vendors for the PC version?
> 
> I bought the PC-version of Hspice for the following reasons:
> 
> (1) Cheaper
> 
> The software is $5K and so is a fast Pentium PC with 32M of RAM. Total
> solution cost is ~$10K. The Unix version is ~$21K and a Sparc5 (32M of
> memory) is ~$7.5K. Total solution cost is $28.5K. (I think the PC is
> even faster than the SparcStation).
> 
> (2) I forget
> 
> I don't want to hold up this e-mail while I try to remember the other
> reason (just another example of why you should write in outline
> (brain-dump) form first and wordsmith it later). :)
> 
> The sales literature, form 73302/4.95/1M, mentions very little about
> proprietary model support, and nothing about the PC version supporting
> less than the Unix version.
> 
> Do I have to spend more money, (i.e. get the Unix version), to get
> the model support? And if the answer is "yes", should I go ahead and
> take a closer look at some of the other more full-featured signal
> integrity tools?
> 
> Any and all input and suggestions will be appreciated.
> 
> 
> Thank you
>      Don Abernathey
> 
> Text item: External Message Header
> 
> The following mail header is for administrative use
> and may be ignored unless there are problems.
> 
> ***IF THERE ARE PROBLEMS SAVE THESE HEADERS***.
> 
> Content-Type: text/plain; charset=us-ascii
> Mime-Version: 1.0
> Cc: dla@pyrodactyl.or.pyramid.com
> Subject: Model availability for DOS Hspice..
> To: si-list@silab.Eng.Sun.COM
> X-Mailer: Z-Mail (3.2.0 06sep94)
> Date: Wed, 11 Oct 1995 12:04:15 -0700
> Message-Id: <9510111204.ZM17811@pyrodactyl.or.pyramid.com>
> From: "Don Abernathey" <dla@pyramid.com>
> Received: by pyrodactyl.or.pyramid.com (5.67/Pyramid_Internal_Configuration)
>      id AA17813; Wed, 11 Oct 95 19:04:16 GMT
> Received: from pyrodactyl.or.pyramid.com
>      by gossip.pyramid.com (5.61/OSx5.1a Pyramid-Internet-Gateway)
>      id AA27229; Wed, 11 Oct 95 12:04:19 -0700
> Received: from gossip.pyramid.com by mercury.Sun.COM (Sun.COM)
>      id MAA06982; Wed, 11 Oct 1995 12:04:22 -0700
> Received: from mercury.Sun.COM (mercury.EBay.Sun.COM) by Eng.Sun.COM
> (5.x/SMI-5.
> 3)
>      id AA08751; Wed, 11 Oct 1995 12:04:23 -0700
> Received: from Eng.Sun.COM (engmail1) by silab.Eng.Sun.COM (4.1/SMI-4.1)
>      id AA03453; Wed, 11 Oct 95 12:04:41 PDT
> Received: from silab.Eng.Sun.COM (silab-188.Eng.Sun.COM) by Eng.Sun.COM
> (5.x/SMI
> -5.3)
>      id AA23045; Wed, 11 Oct 1995 12:08:08 -0700
> Received: from Eng.Sun.COM by mercury.Sun.COM (Sun.COM)
>      id MAA08119; Wed, 11 Oct 1995 12:08:26 -0700
> Received: from mercury.Sun.COM by aurora.intel.com (5.65/10.0i); Wed,
> 11 Oct 95
> 12:25:51 -0700
> Received: from aurora.intel.com by fmmail.fm.intel.com with smtp
>      (Smail3.1.28.1 #2) id m0t36lM-000rJpC; Wed, 11 Oct 95 12:24 PDT
> 
> Text item: External Message Header
> 
> The following mail header is for administrative use
> and may be ignored unless there are problems.
> 
> ***IF THERE ARE PROBLEMS SAVE THESE HEADERS***.
> 
> From: Stephen Peters <speters@ichips.intel.com>
> Date: Wed, 11 Oct 1995 15:52:35 -0700
> Subject: Re: Model availability for DOS Hspice..
> Cc: Arpad_Muranyi@ccm.fm.intel.com
> To: dla@pyramid.com, si-list@silab.Eng.Sun.COM, ibis@vhdl.org
> Message-Id: <9510112252.AA14562@xtg801.intel.com>
> Received: from localhost by xtg801.intel.com (4.1/10.0i); Wed, 11 Oct 95 15:52:3
> 6 PDT
> Received: from xtg801 by ichips.intel.com (5.64+/10.0i); Wed, 11 Oct 95 15:52:37
>  -0700
> Received: from ichips.intel.com by hermes.intel.com (5.65/10.0i); Wed, 11 Oct 95
>  15:52:47 -0700
> Received: from hermes.intel.com by fmmail.fm.intel.com with smtp
>      (Smail3.1.28.1 #2) id m0t3A14-000rHfC; Wed, 11 Oct 95 15:52 PDT
> 


From day_d@sanjose.vlsi.com  Thu Oct 12 08:02:50 1995
Return-Path: <day_d@sanjose.vlsi.com>
Received: from relayhost.vlsi.com (tweety.vlsi.com) by vhdl.vhdl.org (4.1/SMI-4.1/BARRNet)
	id AA28535; Thu, 12 Oct 95 08:02:50 PDT
Received: from vlsisj.sanjose.vlsi.com ([180.0.0.29]) by relayhost.vlsi.com (8.6.12/Hub-Perlotto/050895) with SMTP id IAA21787 for <ibis@vhdl.org>; Thu, 12 Oct 1995 08:19:03 -0700
Received: from hobbes.nwpd (hobbes.sanjose.vlsi.com) by vlsisj.sanjose.vlsi.com (4.1/SMI-4.1-MHS-7.0-owen@delong.sj.ca.us-9409021800)
	id AA24452; Thu, 12 Oct 95 07:57:57 PDT
Reply-To: day_d@sanjose.vlsi.com
Received: by hobbes.nwpd (4.1/SMI-4.1)
	id AA01573; Thu, 12 Oct 95 08:02:06 PDT
Date: Thu, 12 Oct 95 08:02:06 PDT
From: day_d@sanjose.vlsi.com (Doug Day)
Message-Id: <9510121502.AA01573@hobbes.nwpd>
To: ibis@vhdl.org
Subject: subscribe
Cc: day_d@sanjose.vlsi.com

Could you please add my name to the distribution list for the IBIS refelctor?

thank you.

doug.day@sanjose.vlsi.com


Doug Day
Applications Engineer
Network Products Division
VLSI Technology

From huq@rockie.nsc.com  Thu Oct 12 09:57:48 1995
Return-Path: <huq@rockie.nsc.com>
Received: from gatekeeper.nsc.com by vhdl.vhdl.org (4.1/SMI-4.1/BARRNet)
	id AA28951; Thu, 12 Oct 95 09:57:48 PDT
Received: from nsc.nsc.com by gatekeeper.nsc.com (5.65/fma-120691) with SMTP;
	id AA01498 for ibis@vhdl.org; Thu, 12 Oct 95 09:50:28 -0700
Received: from lightning-gw.nsc.com by nsc.nsc.com (5.65/1.34) with SMTP
	id AA13352 for ibis@vhdl.org; Thu, 12 Oct 95 09:50:26 -0700
Received: from kural by rockie.nsc.com (4.1/SMI-4.1)
	id AA28081; Thu, 12 Oct 95 09:50:35 PDT
Date: Thu, 12 Oct 95 09:50:35 PDT
From: huq@rockie.nsc.com (Syed Huq)
Message-Id: <9510121650.AA28081@rockie.nsc.com>
To: ibis@vhdl.org
Subject: Face to Face 1996 ..
Cc: huq@rockie.nsc.com

IBISgurus,

I have checked the calendar for Design SuperCon96 and the dates
are as follows:

     Jan 30th(Tue) through Feb 1st(Thurs) in Santa Clara, CA

Our options are either "Monday Jan 29th" or "Friday Feb2nd"

We need to decide on a date so National can start making arrangements
for the face to face meeting.

Comments welcome..

Syed.
National Semiconductor

From bob@icx.com  Thu Oct 12 11:43:53 1995
Return-Path: <bob@icx.com>
Received: from icx.com (icx.rain.com) by vhdl.vhdl.org (4.1/SMI-4.1/BARRNet)
	id AA29401; Thu, 12 Oct 95 11:43:53 PDT
Received: by icx.com (/\==/\ Smail3.1.28.1 #28.14)
	id <m0t3SUF-000FVWC@icx.com>; Thu, 12 Oct 95 11:36 PDT
Received: by icx.com (/\==/\ Smail3.1.28.1 #28.14)
	id <m0t3Qx7-000GjSC@icx.com>; Thu, 12 Oct 95 09:57 PDT
Message-Id: <m0t3Qx7-000GjSC@icx.com>
Date: Thu, 12 Oct 95 11:38 PDT
From: bob@icx.com ( Bob Ross)
To: ibis@vhdl.org
Subject: CONNECTOR/CABLE EGGS

To All:

CONNECTOR/CABLE EGGS

The package formats in IBIS 1.1, 2.1 and BIRD28.3 present a format that can
be used for modeling connectors and can be extended to cables.  An outline of
a proposal is given below.  Thanks to Chris Reid for suggesting this approach.

CONNECTOR MODELS

The standard package model specifies the C_pkg or C_pin and works inward
to the DIE.  If the package model split between two boards is JOINED at
the DIE position, the existing set of package models can be used for
two-board connections without any changes in the IBIS Specification.
Some rules for joining are proposed along with some examples.

(1) The package model data defined by the default values in [Package],
by the per pin values in [Pin] or by the matrices in Version 2.1 of [Define
Package Model] are connected at the DIE position.

(2) For BIRD28.3 extensions, only the first section is considered for 
joining two connectors.  

(3) An IBIS Terminator model may be included at the joining point for 
cases where the connector itself has some built in pullup or clamping
elements.  Otherwise, NC, POWER, and GND are permissible Model_name entries 
in the [Pin] keyword.  Note, the point at which the connectors join is similar
to where the DIE begins in the standard IBIS format and would be the position
of the Terminator model.  The proposal here includes the Terminator model
so that an element such as C_comp can be inserted in the middle.  It would
be an issue whether to allow such a model or models on each board, and also
whether to allow the complete set of other Model_types. 

So the connector models may look like this:

a) Using the [Package] default C_pkg, L_pkg, R_pkg:


 BOARD 1, PIN 1                  Connection                  BOARD 2, PIN 1
                L_pkg    R_pkg       V        R_pkg    L_pkg
      o-----+---@@@@@---/\/\/\-------+--------/\/\/\---@@@@@---+-----o
            |                     ___|___                      |
            |                NC, |       | Optional            |
          __|__        POWER or, |       | Terminator        __|__
    C_pkg _____          GND or  |       | Model(s)          _____ C_pkg
            |                    |_______|                     |
            |                        |                         |            
           GND             GND, Gnd_Clamp Reference,          GND
                           or Power Clamp Reference

b) Using the [Pin] C_pin, L_pin, R_pin:


 BOARD 1, PIN 2                  Connection                  BOARD 2, PIN 2
                L_pin    R_pin       V        R_pin    L_pin
      o-----+---@@@@@---/\/\/\-------+--------/\/\/\---@@@@@---+-----o
            |                     ___|___                      |
            |                NC, |       | Optional            |
          __|__        POWER or, |       | Terminator        __|__
    C_pin _____          GND or  |       | Model(s)          _____ C_pin
            |                    |_______|                     |
            |                        |                         |            
           GND             GND, Gnd_Clamp Reference,          GND
                           or Power Clamp Reference


c) Using Version 2.1 [Define Package Model] extension:

 BOARD 1, PIN 3                  Connection                  BOARD 2, PIN 3
                 [L]     [R]         V         [R]      [L]
      o-----+---@@@@@---/\/\/\-------+--------/\/\/\---@@@@@---+-----o
            |                     ___|___                      |
            |                NC, |       | Optional            |
          __|__        POWER or, |       | Terminator        __|__
      [C] _____          GND or  |       | Model(s)          _____ [C]
            |                    |_______|                     |
            |                        |                         |            
           GND             GND, Gnd_Clamp Reference,          GND
                           or Power Clamp Reference


    [C] represents the [Capacitance Matrix] elements
    [L] represents the [Inductance Matrix] elements
    [R] represents the [Resistance Matrix] elements

d) Using BIRD28.3 [Pin Numbers] per unit length Matrix extension:


| Pin   Model
  4     / Len=xx Matrix / ..... /

 BOARD 1, PIN 4                  Connection                  BOARD 2, PIN 4
               [L],Len  [R],Len      V       [R],Len  [L],Len
      o-----+---@@@@@---/\/\/\-------+--------/\/\/\---@@@@@---+-----o
            |                     ___|___                      |
            |                NC, |       | Optional            |
          __|__        POWER or, |       | Terminator        __|__
  Len,[C] _____          GND or  |       | Model(s)          _____ Len,[C]
            |                    |_______|                     |
            |                        |                         |            
           GND             GND, Gnd_Clamp Reference,          GND
                           or Power Clamp Reference

    Len, [C] are the [Capacitance Matrix] per unit length elements and length
    Len, [L] are the [Inductance Matrix] per unit length elements and length
    Len, [R] are the [Resistance Matrix] per unit length elements and length


e) Using BIRD28.3 [Pin Numbers] per unit length Component or Transmission Line:

| Pin   Model
  5     / Len=xx R=xx C=yy L=zz / ..... /

 BOARD 1, PIN 6                  Connection                  BOARD 2, PIN 5
                L,Len   R,Len        V        R,Len    L,Len
      o-----+---@@@@@---/\/\/\-------+--------/\/\/\---@@@@@---+-----o
            |                     ___|___                      |
            |                NC, |       | Optional            |
          __|__        POWER or, |       | Terminator        __|__
    Len,C _____          GND or  |       | Model(s)          _____ Len,C
            |                    |_______|                     |
            |                        |                         |            
           GND             GND, Gnd_Clamp Reference,          GND
                           or Power Clamp Reference

    Len, C are the capacitance per unit length elements and length
    Len, L are the inductance per unit length elements and length
    Len, R are the resistance per unit length elements and length

f) Using BIRD28.3 [Pin Numbers] extension for discrete components:

| Pin   Model
  6     / Len=0 R=xx C=yy L=zz / ..... /

 BOARD 1, PIN 6                  Connection                  BOARD 2, PIN 6
                  L       R          V          R        L
      o-----+---@@@@@---/\/\/\-------+--------/\/\/\---@@@@@---+-----o
            |                     ___|___                      |
            |                NC, |       | Optional            |
          __|__        POWER or, |       | Terminator        __|__
        C _____          GND or  |       | Model(s)          _____ C
            |                    |_______|                     |
            |                        |                         |            
           GND             GND, Gnd_Clamp Reference,          GND
                           or Power Clamp Reference

    Len, [C] are the [Capacitance Matrix] per unit length elements and length
    Len, [L] are the [Inductance Matrix] per unit length elements and length
    Len, [R] are the [Resistance Matrix] per unit length elements and length


With the above structure, the existing IBIS Version 1.1 format can be used
without change to model some standard, uncoupled connectors, and Version 2.1
[Define Package Model] can be used to model up to two sections of matrix
coupling between lines.  BIRD28.3 provides an extended syntax to include
much more detail and also transmission line segments.  

The connector model components would be divided into two models.  The examples
above show some symmetrical division and also relate to the existing default 
package model.  There would be no restriction that the connection models for
each board would have to be symmetrical or even of the same structure.  So 
the Board 1 structure could be the default package parameters, and the board 2 
structure could be a coupled matrix.  However, such mixing would not be 
expected to be a common practice and may produce unusual results if a 
particular connection is open.

The Terminator models could provide a termination if a particular connection
is left disconnected.  Since connector models assume a connection, the 
model for an un-connected pin may be a less accurate approximation.


CABLE MODELS

The BIRD28.3 provides the syntax and a set of elements that could also be
used for modeling CABLES.  Without BIRD28.3, a very crude LUMPED approximation
is available using the CONNECTOR model structure elements above.  With
BIRD28.3 a middle cable section can be included to model the longer wire.

However, such an approach does not support CABLES as independent components
with CONNECTORS on each end and with non-direct paths.  The proposal here is
to generalize a [Define Cable Model] keyword ALMOST identical to the [Define
Package Model] syntax.  There would be some differences, however, which
justifies a separate keyword.  The major differences would be:

(1) At least two Sections would be required, and the FIRST and LAST sections
define the connection interfaces similar to the CONNECTOR model.  These
could be joined with board CONNECTOR models or with another CABLE Model.
The LAST section of a CABLE model would be treated in a mirror image
manner so that the connection point with L, R and C given is through the L
and R elements.

(2) Two columns of Pin numbers would be supported so that split cables and
cables with paths joining, for example, pin 1 on one end and pin 2 on the
other end could be modeled.  Also, paths for pin 1 joining several pins
could also be modeled.  Two columns would also allow supporting different
connector A and connector B pin numbering syntax.  In the example below,
[Cable Pin Numbers] has the [Pin Numbers] syntax, but requires two columns
of pin numbers.

(3) The [Component] description for Cables would have to describe all of 
the pins on each end.  To avoid redundant pin numbers the [Pin] keyword
under [Component] may have to have a sub-parameter to separate the Side A
and side B groupings.  Another approach would be to use a [Component]
keyword and name for side A and another [Component] keyword and name for
side B.  The details of these alternatives are not considered here.

(4) A separate provision might be made for jumpers.  A syntax example is
shown below using [Jumper Table].  Whether to provide such support would be
an issue.  

With such extensions, this complicated path could be modeled:

   BOARD 1                    CABLE                    BOARD 2
       _____    Connector A          Connector B    ______
            |   First Section       Last Section   |
           +-+ +-+                            +-+ +-+
           |-|-|1|-------------\/-------------|1|-|-|
           |-|-|2|-------------/\-------------|2|-|-|
   Board 1 |-|-|3|----------------------------|3|-|-| Board 2
 Connector |-|-|4|-\--------------------------|4|-|-| Connector
           |-|-|5|  \-------------------------|5|-|-|
           |-|-|6|--------------------------|-|6|-|-|
           |-|-|7|                          |-|7|-|-|
           |-|-|8|-|                        | |8|-|-|
           |-|-|9|-|                        |-|9|-|-|
           |-|-|0|  ------------------------  |0|-|-|
           +-+ +-+                            +-+ +-+
            |                                      |
            |                                      |

[Cable Pin Numbers]
|  A   B     First Section   .....   Last Section
|
   1   2     Len ... /       .....   Len ... /
   2   1     Len ... /       .....   Len ... /
   3   3     Len ... /       .....   Len ... /
   4   4     Len ... /       .....   Len ... /
   4   5     Len ... /       .....   Len ... /
   5   5     Len ... /       .....   Len ... /  | "Open" Middle, Last Sections
   6   6     Len ... /       .....   Len ... /
   7   7     Len ... /       .....   Len ... /  | "Open" Middle Sections
   8   8     Len ... /       .....   Len ... /  | "Open" Middle Sections
   9   9     Len ... /       .....   Len ... /  | "Open" Middle Sections
   0   0     Len ... /       .....   Len ... /  | "Open" First, Last Sections
|
[Jumper Table]
| Side  Pin Pin
   A    8   9
   B    6   7    
   B    7   9

The simulator would have the necessary information for keeping track of the
connecting paths between boards.  The attachment of Connector and Cable
models would be through the Component Names with assumed identical pin
numbers at the connection points.  Board1 to Cable side A to Cable side B
to Board2 might flow like this:

   BOARD1-CONNECTOR
   CABLE_A
   CABLE_B
   BOARD2-CONNECTOR

Bob Ross,
Interconnectix, Inc.





From ventham@quantic.mb.ca  Thu Oct 12 15:13:33 1995
Return-Path: <ventham@quantic.mb.ca>
Received: from access.mbnet.mb.ca by vhdl.vhdl.org (4.1/SMI-4.1/BARRNet)
	id AA00361; Thu, 12 Oct 95 15:13:33 PDT
Received: by access.mbnet.mb.ca with UUCP id AA16657
  (5.67b/IDA-1.4.4 for ibis@vhdl.org); Thu, 12 Oct 1995 17:05:00 -0500
Received: by quantic.mb.ca (4.1/SMI-4.1)
	id AA03462; Thu, 12 Oct 95 16:27:08 CDT
From: ventham@quantic.mb.ca (Mike Ventham)
Message-Id: <9510122127.AA03462@quantic.mb.ca>
Subject: Re: Xilinx model library available soon
To: 71436.1314@compuserve.com (Kellee Crisafulli)
Date: Thu, 12 Oct 95 16:27:07 CDT
Cc: ibis@vhdl.org
In-Reply-To: <941117195339_71436.1314_HHB25-1@CompuServe.COM>; from "Kellee Crisafulli" at Nov 17, 94 2:53 pm
X-Mailer: ELM [version 2.3 PL11]

> 
> From: Kellee Crisafulli, HyperLynx
> 
> An FYI bit of good news.
> 
> I spoke to Kerry Pierce at Xilinx and offered to give Xilinx 
> the complete model library of Xilinx models we have developed
> in exchange for Xilinx's assurance that all the models that they
> create will be placed in the public domain.
> 
> I spoke to Kerry yesterday and he received confirmation from
> their marketing department that Xilinx has agreed to place all the
> IBIS models they develop in public domain.
> 
> Based on this word of mouth agreement I have emailed the model
> library to Xilinx.
> 
> They may choose to make some or all of these models available
> immediately, or wait and develop all the models in-house.
> 
Kellee,

Whatever happened to these models? The original e-mail was in Nov 94!

Regards

Mike
+======================================================================+
| Mike Ventham - Vice President Engineering, Quantic Laboratories Inc, |
| 12th Floor, 191 Lombard Ave, Winnipeg, Manitoba, Canada R3B 0X1      |
| Tel: (204) 942 4000 Fax: (204) 957 1158 Email: ventham@quantic.mb.ca |
+======================================================================+

From Will_Hobbs@ccm.jf.intel.com  Thu Oct 12 19:21:30 1995
Return-Path: <Will_Hobbs@ccm.jf.intel.com>
Received: from ormail.intel.com by vhdl.vhdl.org (4.1/SMI-4.1/BARRNet)
	id AA01323; Thu, 12 Oct 95 19:21:30 PDT
Received: from relay.jf.intel.com by ormail.intel.com with smtp
	(Smail3.1.28.1 #7) id m0t3ZdR-000UfcC; Thu, 12 Oct 95 19:14 PDT
Received: from ccm.jf.intel.com by relay.jf.intel.com
	(Smail3.1.28.1 #2) id m0t3ZdQ-000twWC; Thu, 12 Oct 95 19:14 PDT
Received: by ccm.jf.intel.com (ccmgate 3.2 #3) Thu, 12 Oct 95 19:14:08 PDT
Date: Thu, 12 Oct 95 13:11:00 PDT
From: Will Hobbs <Will_Hobbs@ccm.jf.intel.com>
Message-Id: <Thu, 12 Oct 95 19:14:03 PDT_2@ccm.jf.intel.com>
To: ibis@vhdl.org
Cc: huq@rockie.nsc.com
Subject: Re: Face to Face 1996 ..


Text item: 

Syed and other IBIS-folk,

Will we have less participation if we hold it on Monday because people are 
preparing for their participation in SuperCon96? Conversely, if we have it on 
Friday, will people be too burned out to attend? I've seen the "after the 
conference" approach work very well, so Friday would be my vote, but I could 
attend either way.

Will

IBISgurus,

I have checked the calendar for Design SuperCon96 and the dates 
are as follows:

     Jan 30th(Tue) through Feb 1st(Thurs) in Santa Clara, CA

Our options are either "Monday Jan 29th" or "Friday Feb2nd"

We need to decide on a date so National can start making arrangements 
for the face to face meeting.

Comments welcome..

Syed.
National Semiconductor

Text item: External Message Header

The following mail header is for administrative use
and may be ignored unless there are problems.

***IF THERE ARE PROBLEMS SAVE THESE HEADERS***.

Cc: huq@rockie.nsc.com
Subject: Face to Face 1996 ..
To: ibis@vhdl.org
Message-Id: <9510121650.AA28081@rockie.nsc.com>
From: huq@rockie.nsc.com (Syed Huq)
Date: Thu, 12 Oct 95 09:50:35 PDT
Received: from kural by rockie.nsc.com (4.1/SMI-4.1)
     id AA28081; Thu, 12 Oct 95 09:50:35 PDT
Received: from lightning-gw.nsc.com by nsc.nsc.com (5.65/1.34) with SMTP
     id AA13352 for ibis@vhdl.org; Thu, 12 Oct 95 09:50:26 -0700
Received: from nsc.nsc.com by gatekeeper.nsc.com (5.65/fma-120691) with SMTP;
     id AA01498 for ibis@vhdl.org; Thu, 12 Oct 95 09:50:28 -0700
Received: from gatekeeper.nsc.com by vhdl.vhdl.org (4.1/SMI-4.1/BARRNet)
     id AA28951; Thu, 12 Oct 95 09:57:48 PDT
Received: from vhdl.vhdl.org by hermes.intel.com (5.65/10.0i); Thu, 12 Oct 95 10
:58:41 -0700
Received: from hermes.intel.com by ichips.intel.com (5.64+/10.0i); Thu, 12 Oct 9
5 10:59:31 -0700
Received: from ichips.intel.com by relay.jf.intel.com with smtp
     (Smail3.1.28.1 #2) id m0t3Ruo-000twVC; Thu, 12 Oct 95 10:59 PDT

From speters@ichips.intel.com  Fri Oct 13 08:58:04 1995
Return-Path: <speters@ichips.intel.com>
Received: from hermes.intel.com by vhdl.vhdl.org (4.1/SMI-4.1/BARRNet)
	id AA08506; Fri, 13 Oct 95 08:58:04 PDT
Received: from ichips.intel.com by hermes.intel.com (5.65/10.0i); Fri, 13 Oct 95 08:50:43 -0700
Received: from xtg801 by ichips.intel.com (5.64+/10.0i); Fri, 13 Oct 95 08:50:37 -0700
Received: from localhost by xtg801.intel.com (4.1/10.0i); Fri, 13 Oct 95 08:50:36 PDT
Message-Id: <9510131550.AA02363@xtg801.intel.com>
To: huq@rockie.nsc.com
Cc: ibis@vhdl.org
Subject: Picture for EDN artical
Date: Fri, 13 Oct 1995 08:50:35 -0700
From: Stephen Peters <speters@ichips.intel.com>

Hello Syed:

     I have found the original waveform picture that I
gave to Derrick Duehren for the EDN artical.  Unfortunetly,
I don't have the electronic copy (i.e. the Excel spreedsheet
that it came from), so I will have to fax it to you.  If you
have any questions, please call.

               Regards,
               Stephen Peters
               Intel Corp.

From Will_Hobbs@ccm.jf.intel.com  Fri Oct 13 09:44:09 1995
Return-Path: <Will_Hobbs@ccm.jf.intel.com>
Received: from ormail.intel.com by vhdl.vhdl.org (4.1/SMI-4.1/BARRNet)
	id AA08661; Fri, 13 Oct 95 09:44:09 PDT
Received: from relay.jf.intel.com by ormail.intel.com with smtp
	(Smail3.1.28.1 #7) id m0t3n5S-000UjJC; Fri, 13 Oct 95 09:35 PDT
Received: from ccm.jf.intel.com by relay.jf.intel.com
	(Smail3.1.28.1 #2) id m0t3n5E-000twWC; Fri, 13 Oct 95 09:35 PDT
Received: by ccm.jf.intel.com (ccmgate 3.2 #3) Fri, 13 Oct 95 09:35:44 PDT
Date: Fri, 13 Oct 95 09:32:00 PDT
From: Will Hobbs <Will_Hobbs@ccm.jf.intel.com>
Message-Id: <Fri, 13 Oct 95 09:34:42 PDT_7@ccm.jf.intel.com>
To: bob@icx.com, ibis@vhdl.org
Subject: Re: CONNECTOR/CABLE EGGS

Bob, et al,

To continue a somewhat fragile and unofficial tradition, let's call the 
connector/cable egg Egg 7.

Will Hobbs
Intel Corp.

From WLeilich@stgl.sel.alcatel.de  Fri Oct 13 15:07:24 1995
Return-Path: <WLeilich@stgl.sel.alcatel.de>
Received: from slsa02t.stgl.netd.alcatel.de by vhdl.vhdl.org (4.1/SMI-4.1/BARRNet)
	id AA09970; Fri, 13 Oct 95 15:07:24 PDT
Received: from slsd12.stgl.sel.alcatel.de by slsa02t.stgl.netd.alcatel.de 
          with SMTP (PP) id <29174-0@slsa02t.stgl.netd.alcatel.de>;
          Fri, 13 Oct 1995 22:51:14 +0100
Received: from slsd45 by slsd12.stgl.sel.alcatel.de (4.1/SMI-4.1-DNI-7.0.1) 
          id AA29344; Fri, 13 Oct 95 12:41:25 +0100
Date: Fri, 13 Oct 95 12:41:25 +0100
From: WLeilich@stgl.sel.alcatel.de (W.Leilich tel +711.821.44109 fax .44084 )
Message-Id: <9510131141.AA29344@slsd12.stgl.sel.alcatel.de>
To: ibis@vhdl.org
Subject: unsubscribe
Cc: WLeilich@stgl.sel.alcatel.de

Hello,
please remove my address from the IBIS mailing list.

unsubscribe WLeilich@stgl.sel.alcatel.de

From Arpad_Muranyi@ccm.fm.intel.com  Mon Oct 16 09:24:17 1995
Return-Path: <Arpad_Muranyi@ccm.fm.intel.com>
Received: from ormail.intel.com by vhdl.vhdl.org (4.1/SMI-4.1/BARRNet)
	id AA06390; Mon, 16 Oct 95 09:24:17 PDT
Received: from relay.jf.intel.com by ormail.intel.com with smtp
	(Smail3.1.28.1 #7) id m0t4sDc-000UjUC; Mon, 16 Oct 95 09:16 PDT
Received: from ccm.hf.intel.com by relay.jf.intel.com
	(Smail3.1.28.1 #2) id m0t4sDb-000twWC; Mon, 16 Oct 95 09:16 PDT
Received: by ccm.hf.intel.com (ccmgate 3.2 #3) Mon, 16 Oct 95 09:16:51 PDT
Date: Mon, 16 Oct 95 09:10:00 PDT
From: Arpad Muranyi <Arpad_Muranyi@ccm.fm.intel.com>
Message-Id: <Mon, 16 Oct 95 09:15:42 PDT_10@ccm.hf.intel.com>
To: bob@icx.com, ibis@vhdl.org
Subject: Re: IBIS MINUTES 10/6/95


Text item: 

Bob,

I did not see it written down in the minutes, that I mentioned that the added 
disclaimer should be appended to the existing one without repeating the keyword 
"Disclaimer" if a disclaimer already exists in the file.

I favor this approach vs. the comment character approach ("|") because comments 
are most often ignored.  Disclaimers are more important, and they sould not be 
ignored like comments.

Arpad
================================================================================
 GOLDEN PARSER UPDATE
 A bug producing a "BUG" versus the correct "ERROR" message has been
 discovered in the Beta 9 release (and earlier versions) when [Package]
 is omitted entirely.  The corrections is minor, so a small test version
 is being distributed to validate the fix.  Upon approval, the final
 release will be put on vhdl.org.  Bob Ross reported that the ibischk2
 directory is in place.

 Another difference has been recently discovered.  IBIS Version 1.1
 supports multiple [Disclaimer] keywords, but when the files are designated
 Version 2.1, an error is reported.  This impacts attaching the generic
 IBIS disclaimer along with the disclaimer within the model.  The work
 around is to put the "|" in front of the IBIS disclaimer or to eliminate
 the second keyword entirely.  It was decided not to fix this problem
 at this time (causing further delay), but to wait until a possible
 future correction release if other probems are found.

 Once the corrected ibischk2 is checked, the process to post it will
 be done through Jon Powell to make the executables, and Bob Ross to
 put them on vhdl.org per AR's of the last meeting.

 AR - Bob Ross post a note when ibischk2 version 10 is checked. [Done]

Text item: External Message Header

The following mail header is for administrative use
and may be ignored unless there are problems.

***IF THERE ARE PROBLEMS SAVE THESE HEADERS***.

Subject: IBIS MINUTES 10/6/95
To: ibis@vhdl.org
From: bob@icx.com ( Bob Ross)
Date: Wed, 11 Oct 95 10:30 PDT
Message-Id: <m0t34yk-000GjSC@icx.com>
Received: by icx.com (/\==/\ Smail3.1.28.1 #28.14)
     id <m0t34yk-000GjSC@icx.com>; Wed, 11 Oct 95 10:30 PDT
Received: by icx.com (/\==/\ Smail3.1.28.1 #28.14)
     id <m0t34wB-000FVWC@icx.com>; Wed, 11 Oct 95 10:27 PDT
Received: from icx.com (icx.rain.com) by vhdl.vhdl.org (4.1/SMI-4.1/BARRNet)
     id AA19211; Wed, 11 Oct 95 10:34:58 PDT
Received: from vhdl.vhdl.org by aurora.intel.com (5.65/10.0i); Wed, 11 Oct 95 10
:32:37 -0700
Received: from aurora.intel.com by relay.jf.intel.com with smtp
     (Smail3.1.28.1 #2) id m0t352u-000txHC; Wed, 11 Oct 95 10:34 PDT

From kellee@washington.nwlink.com  Mon Oct 16 10:56:54 1995
Return-Path: <kellee@washington.nwlink.com>
Received: from washington.nwlink.com (nwlink.com) by vhdl.vhdl.org (4.1/SMI-4.1/BARRNet)
	id AA06722; Mon, 16 Oct 95 10:56:54 PDT
Received: (from kellee@localhost) by washington.nwlink.com (8.6.12/8.6.12) id KAA27267; Mon, 16 Oct 1995 10:42:30 -0700
Date: Mon, 16 Oct 1995 10:42:30 -0700
Message-Id: <199510161742.KAA27267@washington.nwlink.com>
X-Sender: kellee@hyperlynx.com
X-Mailer: Windows Eudora Pro Version 2.1.2
Mime-Version: 1.0
Content-Type: text/plain; charset="us-ascii"
To: ibis@vhdl.org
From: Kellee Crisafulli <kellee@hyperlynx.com>
Subject: Spice to IBIS for windows

I am trying to compile the spice to IBIS converter
to run under windows/3.1, 95, NT and am having trouble
getting some of the lex functions to compile.

If I can get it to compile I will send it to Michel Steer.


Who is the best contact at N.C. about compile problems?



Have a great day...Kellee Crisafulli, HyperLynx Inc.


From kellee@washington.nwlink.com  Mon Oct 16 11:47:57 1995
Return-Path: <kellee@washington.nwlink.com>
Received: from washington.nwlink.com (nwlink.com) by vhdl.vhdl.org (4.1/SMI-4.1/BARRNet)
	id AA06936; Mon, 16 Oct 95 11:47:57 PDT
Received: (from kellee@localhost) by washington.nwlink.com (8.6.12/8.6.12) id LAA01056; Mon, 16 Oct 1995 11:33:33 -0700
Date: Mon, 16 Oct 1995 11:33:33 -0700
Message-Id: <199510161833.LAA01056@washington.nwlink.com>
X-Sender: kellee@hyperlynx.com
X-Mailer: Windows Eudora Pro Version 2.1.2
Mime-Version: 1.0
Content-Type: text/plain; charset="us-ascii"
To: ibis@vhdl.org
From: Kellee Crisafulli <kellee@hyperlynx.com>
Subject: Status of Xilinx IBIS models.

I received email from Terry at Xilinx today.

He told me he has added 2 more models to the set of models he
has already completed (the full XILINX model set is done).

He has been waiting for an OK from the upper management at
Xilinx before he can release the models.

I also just sent emails to two managers at Xilinx to attempt
to help Kerry expedite the model release.


Have a great day...Kellee Crisafulli, HyperLynx Inc.


From mbs@eos.ncsu.edu  Mon Oct 16 13:35:50 1995
Return-Path: <mbs@eos.ncsu.edu>
Received: from mbs.ece.ncsu.edu (c11058-335dan.ece.ncsu.edu) by vhdl.vhdl.org (4.1/SMI-4.1/BARRNet)
	id AA07298; Mon, 16 Oct 95 13:35:50 PDT
Received: by mbs.ece.ncsu.edu (5.65/Eos/C-U-09Sep93)
	id AA03581; Mon, 16 Oct 1995 16:28:23 -0400
From: "Michael B Steer" <mbs@eos.ncsu.edu>
Message-Id: <9510161628.ZM3579@eos.ncsu.edu>
Date: Mon, 16 Oct 1995 16:28:18 -0400
In-Reply-To: Arpad Muranyi <Arpad_Muranyi@ccm.fm.intel.com>
        "Re: IBIS MINUTES 10/6/95" (Oct 16,  9:10am)
References: <Mon  16 Oct 95 09:15:42 PDT_10@ccm.hf.intel.com>
X-Mailer: Z-Mail (3.2.1 15feb95)
To: ibis@vhdl.org
Subject: Re: IBIS Disclaimer issue
Mime-Version: 1.0
Content-Type: text/plain; charset=us-ascii

Arpad wrote


>
> I did not see it written down in the minutes, that I mentioned that the added
> disclaimer should be appended to the existing one without repeating the
keyword
> "Disclaimer" if a disclaimer already exists in the file.
>
> I favor this approach vs. the comment character approach ("|") because
comments
> are most often ignored.  Disclaimers are more important, and they sould not
be
> ignored like comments.
>

I favor this approach and will implement it from now on unless I hear
objections.

Michael Steer
IBIS Librarian

From Will_Hobbs@ccm.jf.intel.com  Mon Oct 16 14:55:51 1995
Return-Path: <Will_Hobbs@ccm.jf.intel.com>
Received: from ormail.intel.com by vhdl.vhdl.org (4.1/SMI-4.1/BARRNet)
	id AA07579; Mon, 16 Oct 95 14:55:51 PDT
Received: from relay.jf.intel.com by ormail.intel.com with smtp
	(Smail3.1.28.1 #7) id m0t4xOI-000UdOC; Mon, 16 Oct 95 14:48 PDT
Received: from ccm.jf.intel.com by relay.jf.intel.com
	(Smail3.1.28.1 #2) id m0t4xOG-000twVC; Mon, 16 Oct 95 14:48 PDT
Received: by ccm.jf.intel.com (ccmgate 3.2 #3) Mon, 16 Oct 95 14:48:12 PDT
Date: Mon, 16 Oct 95 14:44:00 PDT
From: Will Hobbs <Will_Hobbs@ccm.jf.intel.com>
Message-Id: <Mon, 16 Oct 95 14:48:04 PDT_1@ccm.jf.intel.com>
To: mbs@eos.ncsu.edu, ibis@vhdl.org
Subject: Re[2]: IBIS Disclaimer issue


Text item: 

Thanks to Arpad for calling this to our attention. I, too, favor the disclaimer 
amendment approach.  Will

Arpad wrote


>
> I did not see it written down in the minutes, that I mentioned that the added 
> disclaimer should be appended to the existing one without repeating the 
keyword
> "Disclaimer" if a disclaimer already exists in the file. 
>
> I favor this approach vs. the comment character approach ("|") because 
comments
> are most often ignored.  Disclaimers are more important, and they sould not 
be
> ignored like comments.
>

I favor this approach and will implement it from now on unless I hear 
objections.

Michael Steer
IBIS Librarian

Text item: External Message Header

The following mail header is for administrative use
and may be ignored unless there are problems.

***IF THERE ARE PROBLEMS SAVE THESE HEADERS***.

Content-Type: text/plain; charset=us-ascii
Mime-Version: 1.0
Subject: Re: IBIS Disclaimer issue
To: ibis@vhdl.org
X-Mailer: Z-Mail (3.2.1 15feb95)
References: <Mon  16 Oct 95 09:15:42 PDT_10@ccm.hf.intel.com>
In-Reply-To: Arpad Muranyi <Arpad_Muranyi@ccm.fm.intel.com>
        "Re: IBIS MINUTES 10/6/95" (Oct 16,  9:10am)
Date: Mon, 16 Oct 1995 16:28:18 -0400
Message-Id: <9510161628.ZM3579@eos.ncsu.edu>
From: "Michael B Steer" <mbs@eos.ncsu.edu>
Received: by mbs.ece.ncsu.edu (5.65/Eos/C-U-09Sep93)
     id AA03581; Mon, 16 Oct 1995 16:28:23 -0400
Received: from mbs.ece.ncsu.edu (c11058-335dan.ece.ncsu.edu) by vhdl.vhdl.org (4
.1/SMI-4.1/BARRNet)
     id AA07298; Mon, 16 Oct 95 13:35:50 PDT
Received: from vhdl.vhdl.org by hermes.intel.com (5.65/10.0i); Mon, 16 Oct 95 14
:11:41 -0700
Received: from hermes.intel.com by ichips.intel.com (5.64+/10.0i); Mon, 16 Oct 9
5 14:11:50 -0700
Received: from ichips.intel.com by relay.jf.intel.com with smtp
     (Smail3.1.28.1 #2) id m0t4wp6-000twVC; Mon, 16 Oct 95 14:11 PDT

From jonp@qdt.com  Mon Oct 16 15:45:16 1995
Return-Path: <jonp@qdt.com>
Received: from relay3.UU.NET by vhdl.vhdl.org (4.1/SMI-4.1/BARRNet)
	id AA07824; Mon, 16 Oct 95 15:45:16 PDT
Received: from uucp6.UU.NET by relay3.UU.NET with SMTP 
	id QQzlti11046; Mon, 16 Oct 1995 18:36:27 -0400
Received: from qdt.UUCP by uucp6.UU.NET with UUCP/RMAIL
        ; Mon, 16 Oct 1995 18:37:41 -0400
Received: from hal.qdt.com by qdt.com (4.1/SMI-4.1)
	id AA01234; Mon, 16 Oct 95 15:24:55 PDT
Received: from f14.qdt.com by hal.qdt.com (4.1/SMI-4.1)
	id AA04898; Mon, 16 Oct 95 15:23:33 PDT
Date: Mon, 16 Oct 95 15:23:33 PDT
From: jonp@qdt.com (Jon Powell)
Message-Id: <9510162223.AA04898@hal.qdt.com>
Received: by f14.qdt.com (4.1/SMI-4.1)
	id AA02421; Mon, 16 Oct 95 15:22:01 PDT
To: ibis@vhdl.org
Subject: Testing Ports

I have made the first preliminary port of the new IBIS_CHK to a unix platform.
Can anyone send a couple of IBIS files and correct results (errors or no errors)
so I can run some tests?

I should be able to have 4 of 5 platforms supported in a couple of weeks.

jon

From speters@ichips.intel.com  Mon Oct 16 16:12:22 1995
Return-Path: <speters@ichips.intel.com>
Received: from hermes.intel.com by vhdl.vhdl.org (4.1/SMI-4.1/BARRNet)
	id AA07905; Mon, 16 Oct 95 16:12:22 PDT
Received: from ichips.intel.com by hermes.intel.com (5.65/10.0i); Mon, 16 Oct 95 16:05:01 -0700
Received: from xtg801 by ichips.intel.com (5.64+/10.0i); Mon, 16 Oct 95 16:04:54 -0700
Received: from localhost by xtg801.intel.com (4.1/10.0i); Mon, 16 Oct 95 16:04:54 PDT
Message-Id: <9510162304.AA27811@xtg801.intel.com>
To: ibis@vhdl.org
Subject: Enhanced Package Models
Date: Mon, 16 Oct 1995 16:04:52 -0700
From: Stephen Peters <speters@ichips.intel.com>


Hello Kumar, and Fellow IBISans:

     Thank you for taking the time to write up your proposal.  I do
have a couple of questions.  First, in your example, did you really
mean for section #3 of pin A3 to couple to section --> #2 <-- of pin A5
or section #3 of Pin A5.

---------------------- your example

A1  Len = 0 L=1.2n /  Len= 1.3 Matrix=3line MxPinOrder=(A1 A2 A3) /
    Len = 0.47 L=8.35n C=3.34p R=0.01 /
A2  Len = 0 L=1.4n /  Len= 1.2 Matrix=3line MxPinOrder=(A1 A2 A3) /
    Len = 0.47 L=8.35n C=3.34p R=0.01 /
A3  Len = 0 L=1.4n /  Len= 1.1 Matrix=3line MxPinOrder=(A1 A2 A3) /
    Len = 0 Matrix=2line MxPinOrder=(A3 A5) /
A4  Len = 0 L=1.2n / Len = 1.0 L=2nH / Len=0.47 L=8.35
    C=3.34p R=0.01/
A5  Len = 0 L=1.2n /
    Len = 0 Matrix=2line MxPinOrder=(A3 A5) /
    Len = 0.47 L=8.35n C=3.34p R=0.01 /

---------------------
     Second, it is not obvious to me what extra functionality
or problem you are trying to address by adding the matrix names and the
MxPinOrder keywords.  In your example above you want to show coupling
between pins A1, A2 and A3, and also A3 coupling to A5.  This can be
done by using the sparse matrix format as follows (using a capacitance
matrix for illustration):

[Capacitance Matrix]  Sparse_matrix
[Row] 1
1    xxpF
2    yypF
3    zzpF
[Row] 2
2    aapF
3    zzpF
[Row] 3
3    bbpF
5    ccpF
[Row] 4
4    anothervaluepF
.
.
.
[Row] 5
5    stillanothervaluepF
.
.
.
and so on

     I get the feeling I am missing something in your explanation/example.
Please enlighten me.

              Best Regards,
              Stephen Peters
              Intel Corp.





From bob@icx.com  Tue Oct 17 11:08:55 1995
Return-Path: <bob@icx.com>
Received: from icx.com (icx.rain.com) by vhdl.vhdl.org (4.1/SMI-4.1/BARRNet)
	id AA17283; Tue, 17 Oct 95 11:08:55 PDT
Received: by icx.com (/\==/\ Smail3.1.28.1 #28.14)
	id <m0t5GHl-000FVcC@icx.com>; Tue, 17 Oct 95 10:58 PDT
Received: by icx.com (/\==/\ Smail3.1.28.1 #28.14)
	id <m0t5GKL-000GjSC@icx.com>; Tue, 17 Oct 95 11:01 PDT
Message-Id: <m0t5GKL-000GjSC@icx.com>
Date: Tue, 17 Oct 95 11:01 PDT
From: bob@icx.com ( Bob Ross)
To: Arpad_Muranyi@ccm.fm.intel.com, ibis@vhdl.org
Subject: Re: IBIS MINUTES 10/6/95

Arpad:

I also agree with your point.  I will correct the minutes to more clearly state
your comment which got obscured in the "...or to eliminate the keyword
entirely." text.

Bob

> Bob,

> I did not see it written down in the minutes, that I mentioned that the added 
> disclaimer should be appended to the existing one without repeating the keyword 
> "Disclaimer" if a disclaimer already exists in the file.

> I favor this approach vs. the comment character approach ("|") because comments 
> are most often ignored.  Disclaimers are more important, and they sould not be 
> ignored like comments.

> Arpad
> ================================================================================
>  GOLDEN PARSER UPDATE
>  A bug producing a "BUG" versus the correct "ERROR" message has been
>  discovered in the Beta 9 release (and earlier versions) when [Package]
>  is omitted entirely.  The corrections is minor, so a small test version
>  is being distributed to validate the fix.  Upon approval, the final
>  release will be put on vhdl.org.  Bob Ross reported that the ibischk2
>  directory is in place.

>  Another difference has been recently discovered.  IBIS Version 1.1
>  supports multiple [Disclaimer] keywords, but when the files are designated
>  Version 2.1, an error is reported.  This impacts attaching the generic
>  IBIS disclaimer along with the disclaimer within the model.  The work
>  around is to put the "|" in front of the IBIS disclaimer or to eliminate
>  the second keyword entirely.  It was decided not to fix this problem
>  at this time (causing further delay), but to wait until a possible
>  future correction release if other probems are found.

>  Once the corrected ibischk2 is checked, the process to post it will
>  be done through Jon Powell to make the executables, and Bob Ross to
>  put them on vhdl.org per AR's of the last meeting.

>  AR - Bob Ross post a note when ibischk2 version 10 is checked. [Done]

> Text item: External Message Header

> The following mail header is for administrative use
> and may be ignored unless there are problems.

> ***IF THERE ARE PROBLEMS SAVE THESE HEADERS***.

> Subject: IBIS MINUTES 10/6/95
> To: ibis@vhdl.org
> From: bob@icx.com ( Bob Ross)
> Date: Wed, 11 Oct 95 10:30 PDT
> Message-Id: <m0t34yk-000GjSC@icx.com>
> Received: by icx.com (/\==/\ Smail3.1.28.1 #28.14)
>      id <m0t34yk-000GjSC@icx.com>; Wed, 11 Oct 95 10:30 PDT
> Received: by icx.com (/\==/\ Smail3.1.28.1 #28.14)
>      id <m0t34wB-000FVWC@icx.com>; Wed, 11 Oct 95 10:27 PDT
> Received: from icx.com (icx.rain.com) by vhdl.vhdl.org (4.1/SMI-4.1/BARRNet)
>      id AA19211; Wed, 11 Oct 95 10:34:58 PDT
> Received: from vhdl.vhdl.org by aurora.intel.com (5.65/10.0i); Wed, 11 Oct 95 10
> :32:37 -0700
> Received: from aurora.intel.com by relay.jf.intel.com with smtp
>      (Smail3.1.28.1 #2) id m0t352u-000txHC; Wed, 11 Oct 95 10:34 PDT



From cpk@Cadence.COM  Thu Oct 19 07:56:51 1995
Return-Path: <cpk@Cadence.COM>
Received: from mailgate.Cadence.COM by vhdl.vhdl.org (4.1/SMI-4.1/BARRNet)
	id AA07497; Thu, 19 Oct 95 07:56:51 PDT
Received: (from smap@localhost) by mailgate.Cadence.COM (8.6.8/8.6.8) id HAA20545; Thu, 19 Oct 1995 07:49:16 -0700
Received: from cadence.cadence.com(158.140.18.1) by mailgate.cadence.com via smap (V1.0mjr)
	id sma020498; Thu Oct 19 07:49:07 1995
Received: from hot by cadence.Cadence.COM (5.61/3.14)
	id AA08884; Thu, 19 Oct 95 07:49:00 -0700
Received: by hot (5.65+/1.5)
	id AA04988; Thu, 19 Oct 95 10:49:01 -0400
Date: Thu, 19 Oct 95 10:49:01 -0400
From: cpk@cadence.com (C. Kumar)
Message-Id: <9510191449.AA04988@hot>
To: ibis@vhdl.org, speters@ichips.intel.com
Subject: Re: Enhanced Package Models
Content-Type: X-sun-attachment

----------
X-Sun-Data-Type: text
X-Sun-Data-Description: text
X-Sun-Data-Name: text
X-Sun-Content-Lines: 77

Hello:

Sorry I sent the original proposal (enahncement to stephen's package model enhancement (BIRD 28.3)!!) only to Stephen. The thrust of  my attempt is  to

1. Remove the restriction that only adjacent etch can be coupled

2. Remove the restriction that in order to use coupling the adjacent etch should have the same number of sections.

It is my hope these two modifications will make it possible to describe any kind of packages with arbitrary coupling between etch sections. No special restrictions on etch routing (like expecting adjacent pins to have adjacent etches) will be imposed.

I am attaching my original correspondence to Stephen

> 
> 
> Hello Kumar, and Fellow IBISans:
> 
>      Thank you for taking the time to write up your proposal.  I do
> have a couple of questions.  First, in your example, did you really
> mean for section #3 of pin A3 to couple to section --> #2 <-- of pin A5
> or section #3 of Pin A5.
> 
> ---------------------- your example
> 
> A1  Len = 0 L=1.2n /  Len= 1.2 Matrix=3line MxPinOrder=(A1 A2 A3) /
>     Len = 0.47 L=8.35n C=3.34p R=0.01 /
> A2  Len = 0 L=1.4n /  Len= 1.2 Matrix=3line MxPinOrder=(A1 A2 A3) /
>     Len = 0.47 L=8.35n C=3.34p R=0.01 /
> A3  Len = 0 L=1.4n /  Len= 1.2 Matrix=3line MxPinOrder=(A1 A2 A3) /
>     Len = 0 Matrix=2line MxPinOrder=(A3 A5) /
> A4  Len = 0 L=1.2n / Len = 1.0 L=2nH / Len=0.47 L=8.35
>     C=3.34p R=0.01/
> A5  Len = 0 L=1.2n /
>     Len = 0 Matrix=2line MxPinOrder=(A3 A5) /
>     Len = 0.47 L=8.35n C=3.34p R=0.01 /
> 

Yes. I wanted to show how section 2 of pin 2 is coupled to section 2 of pin 3 and section 3 of pin3 is coupled to section 2 of pin 5!! The use of a matrix name and an explicit pin order makes this description possible.

> ---------------------
>      Second, it is not obvious to me what extra functionality
> or problem you are trying to address by adding the matrix names and the
> MxPinOrder keywords.  In your example above you want to show coupling
> between pins A1, A2 and A3, and also A3 coupling to A5.  This can be
> done by using the sparse matrix format as follows (using a capacitance
> matrix for illustration):
> 
> [Capacitance Matrix]  Sparse_matrix
> [Row] 1
> 1    xxpF
> 2    yypF
> 3    zzpF
> [Row] 2
> 2    aapF
> 3    zzpF
> [Row] 3
> 3    bbpF
> 5    ccpF
> [Row] 4
> 4    anothervaluepF
> .
> .
> .
> [Row] 5
> 5    stillanothervaluepF
> .
> .
> .
> and so on
> 
>      I get the feeling I am missing something in your explanation/example.
> Please enlighten me.
> 
>               Best Regards,
>               Stephen Peters
>               Intel Corp.
> 
The matrix description in the package section is meant to describe complete packages and the pin order includes ALL the package pins. The proposed matrix describing etch coupling can be arbitrarily small or large. The pins to the corresponding to the matrices are explicitly stated in the pin order.
----------
X-Sun-Data-Type: mail-file
X-Sun-Data-Description: mail-file
X-Sun-Data-Name: enh28.3
X-Sun-Encoding-Info: uuencode
X-Sun-Content-Lines: 189

begin 600 enh28.3
M1G)O;2!C<&L@5'5E($]C=" Q," Q.3HP,CHU," Q.3DU"E)E='5R;BU0871H
M.B \8W!K/@I&<F]M.B!C<&L@*$,N($MU;6%R*0I4;SH@<W!E=&5R<T!I8VAI
M<',N:6YT96PN8V]M"E-U8FIE8W0Z(&5N:&%N8V5D('!A8VMA9V4@;6]D96QS
M("AU<&1A=&4@=&\@0DE%1" R."XS*0I#8SH@8W!K"D-O;G1E;G0M3&5N9W1H
M.B X,30W"E@M3&EN97,Z(#$T-@H*4W1E<&5N.@H*4&QE87-E(&=I=F4@;64@
M8V]M96YT<R!O;B!M>2!A='1E;7!T('1O(&5X=&5N9"!P86-K86=E(&-O=7!L
M:6YG('=I=&@@;6EN;W(@"F%M;W5N="!O9B!W;W)K+B *"@H*"DD@86T@<')O
M<&]S:6YG(&9U<G1H97(@96YH86YC96UE;G1S('1O($))4D0@,C@N,PH*(" @
M(" @(" @(" @(" @("!"=69F97(@27-S=64@4F5S;VQU=&EO;B!$;V-U;65N
M=" @*$))4D0I"D))4D0@240C.B @(" @(" @*BHJ"DE34U5%(%1)5$Q%.B @
M(" @16YH86YC96UE;G0@5&\@5&AE(%!A8VMA9V4@36]D96P@*"YP86L@9FEL
M92D@4W!E8VEF:6-A=&EO;@I215%515-415(Z(" @(" @($,N($MU;6%R"D1!
M5$4@4U5"34E45$5$.B @3V-T(#$P+" Q.3DU"D1!5$4@04-#15!4140@0ED@
M24))4R!/4$5.($9/4E5-.B @4&5N9&EN9PH**BHJ*BHJ*BHJ*BHJ*BHJ*BHJ
M*BHJ*BHJ*BHJ*BHJ*BHJ*BHJ*BHJ*BHJ*BHJ*BHJ*BHJ*BHJ*BHJ*BHJ*BHJ
M*BHJ*BHJ*BHJ*BHJ*BHJ"BHJ*BHJ*BHJ*BHJ*BHJ*BHJ*BHJ*BHJ*BHJ*BHJ
M*BHJ*BHJ*BHJ*BHJ*BHJ*BHJ*BHJ*BHJ*BHJ*BHJ*BHJ*BHJ*BHJ*BHJ*BHJ
M*BHJ*@I35$%414U%3E0@3T8@5$A%($E34U5%.B!4:&4@96YH86YC960@<&%C
M:V%G92!M;V1E;" H0DE21" R."XS*2!P;&%C97,@<V]M92!U;FYE8V5S<V%R
M>2!R97-T<FEC=&EO;B!O;B!C;W5P;&5D('-E8W1I;VYS+B!4:&5S92!I;F-L
M=61E('1H92!R97%U:7)E;65N="!O9B!C;W5P;&EN9R!O;FQY(&9O<B!A9&IA
M8V5N="!S96-T:6]N<R!A;F0@=&AE(&%D9&ET:6]N86P@8G5R9&5N(&]F(&AA
M=FEN9R!T;R!H879E('1H92!S86UE(&YU;6)E<B!O9B!S96-T:6]N<RX@36EN
M;W(@<F5V:7-I;VYS('!R;W!O<V5D(&AE<F4@=VEL;"!R96UO=F4@=&AE<V4@
M<F5S=')I8W1I;VYS(&%N9"!M86ME('1H92!"25)$(&UO<F4@=6YI=F5R<V%L
M;'D@87!P;&EC86)L92!D:69F97)E;G0@='EP97,@;V8@<&%C:V%G97,N"@HJ
M*BHJ*BHJ*BHJ*BHJ*BHJ*BHJ*BHJ*BHJ*BHJ*BHJ*BHJ*BHJ*BHJ*BHJ*BHJ
M*BHJ*BHJ*BHJ*BHJ*BHJ*BHJ*BHJ*BHJ*BHJ*BHJ*BH*4U1!5$5-14Y4($]&
M(%1(12!215-/3%9%1"!34$5#249)0T%424].4SH@($9O;&QO=VEN9R!A<F4@
M=&AE('-P96-I9FEC(&-H86YG97,*=&\@=&AE('-P96-I9FEC871I;VXN"C$N
M(%1H92!K97EW;W)D(%M.=6UB97(@;V8@4V5C=&EO;G-=(&ES(&YO="!R97%U
M:7)E9"!S:6YC92!V87)I86)L92!N=6UB97(@;V8@"B @('-E8W1I;VYS(&9O
M<B!E86-H('!I;B!I<R!A;&QO=V5D"@H*,BX@5&AE(&-U<G)E;G0@6U!I;B!.
M=6UB97)S72!K97EW;W)D(&1E<V-R:7!T:6]N(&ES(')E<&QA8V5D(&)Y('1H
M92!F;VQL;W=I;F<Z"GP]/3T]/3T]/3T]/3T]/3T]/3T]/3T]/3T]/3T]/3T]
M/3T]/3T]/3T]/3T]/3T]/3T]/3T]/3T]/3T]/3T]/3T]/3T]/3T]/3T]/3T]
M/0I\(" @($ME>7=O<F0Z(%M0:6X@3G5M8F5R<UT*?" @(%)E<75I<F5D.B!9
M97,*?$1E<V-R:7!T:6]N.B!496QL<R!T:&4@<&%R<V5R('1H92!S970@;V8@
M;F%M97,@=&AA="!A<F4@=7-E9"!F;W(@=&AE('!A8VMA9V4*?" @(" @(" @
M(" @("!P:6YS(&%N9"!A;'-O(&1E9FEN97,@<&EN(&]R9&5R:6YG+B @16%C
M:"!P:6X@;G5M8F5R('-H;W5L9" *?" @(" @(" @(" @("!S=&%R="!A<R!T
M:&4@9FER<W0@8VAA<F%C=&5R(&EN(&$@;F5W(&QI;F4N"GP*?"!3=6(M4&%R
M86US.B!,96XL($PL(%(L($,L($UA=')I> I\57-A9V4@4G5L97,Z($9O;&QO
M=VEN9R!T:&4@6U!I;B!.=6UB97)S72!K97EW;W)D+"!T:&4@;F%M97,@;V8@
M=&AE('!I;G,@87)E"GP@(" @(" @(" @(" @;&ES=&5D+B @5&AE<F4@;75S
M="!B92!A<R!M86YY(&YA;65S(&QI<W1E9"!A<R!T:&5R92!A<F4@<&EN<PI\
M(" @(" @(" @(" @("AA<R!G:79E;B!B>2!T:&4@<')E8V5D:6YG(%M.=6UB
M97(@;V8@4&EN<UT@:V5Y=V]R9"DN("!0:6X@;F%M97,*?" @(" @(" @(" @
M("!C86X@;F]T(&5X8V5E9" U(&-H87)A8W1E<G,@:6X@;&5N9W1H+B @5&AE
M(&9I<G-T('!I;B!N86UE"GP@(" @(" @(" @(" @9VEV96X@:7,@=&AE(")L
M;W=E<W0B('!I;BP@86YD('1H92!L87-T('!I;B!G:79E;B!I<R!T:&4*?" @
M(" @(" @(" @(" B:&EG:&5S="XB( I\(" @(" @(" @(" @( I\(" @(" @
M(" @(" @(%-U8G!A<F%M971E<G,Z"GP@(" @(" @(" @(" @5&AE('-U8G!A
M<F%M971E<G,@<W!E8VEF>2!T:&4@;&5N9W1H+"!I;F1U8W1A;F-E+"!C87!A
M8VET86YC90I\(" @(" @(" @(" @(&%N9"!R97-I<W1A;F-E(&]F(&5A8V@@
M<V5C=&EO;B!O9B!E86-H('-T=6(@;VX@82!P86-K86=E+B @268*?" @(" @
M(" @(" @("!A('!A<G1I8W5L87(@<V5C=&EO;B!E>&AI8FET<R!C;W5P;&EN
M9R!T;R!A;B!A9&IA8V5N=" H<V%M90I\(" @(" @(" @(" @(&YU;6)E<F5D
M*2!S96-T:6]N(&]F(&$@9&EF9F5R96YT('!A8VMA9V4@<W1U8B!T:&5N('1H
M92!-871R:7@*?" @(" @(" @(" @("!S=6)P87)A;65T97(@:7,@=7-E9"X@
M(%1H92!S=6)P87)A;65T97)S(&%R92!D969I;F5D(&%S( I\(" @(" @(" @
M(" @(&9O;&QO=W,Z"GP@(" @(" @(" @(" @3&5N(" @("!4:&4@;&5N9W1H
M(&]F(&$@<&%C:V%G92!S='5B('-E8W1I;VXN("!,96YG=&AS(&%R92!G:79E
M;@I\(" @(" @(" @(" @(" @(" @(" @:6X@=&5R;7,@;V8@87)B:71R87)Y
M("=U;FET<R<N"GP@(" @(" @(" @(" @3" @(" @("!4:&4@:6YD=6-T86YC
M92!O9B!A('!A8VMA9V4@<W1U8B!S96-T:6]N+"!I;B!T97)M<R!O9@I\(" @
M(" @(" @(" @(" @(" @(" @)VEN9'5C=&%N8V4O=6YI="!L96YG=&@G+B @
M1F]R(&5X86UP;&4L(&EF('1H92!T;W1A; I\(" @(" @(" @(" @(" @(" @
M(" @:6YD=6-T86YC92!O9B!A('!A8VMA9V4@<W1U8B!S96-T:6]N(&ES(#,N
M,&Y((&%N9"!T:&4*?" @(" @(" @(" @(" @(" @(" @(&QE;F=T:"!O9B!T
M:&ES('-E8W1I;VX@:7,@,B G=6YI=',G+"!T:&4@:6YD=6-T86YC92 *?" @
M(" @(" @(" @(" @(" @(" @('=O=6QD(&)E(&QI<W1E9"!A<R!,(#T@,2XU
M;D@@("AI+F4N(#,N," O(#(I+B *?" @(" @(" @(" @("!#(" @(" @(%1H
M92!C87!A8VET86YC92!O9B!A('!A8VMA9V4@<W1U8B!S96-T:6]N+"!I;B!T
M97)M<R!O9@I\(" @(" @(" @(" @(" @(" @(" @8V%P86-I=&%N8V4@<&5R
M('5N:70@;&5N9W1H+@I\(" @(" @(" @(" @(%(@(" @(" @5&AE($1#("AO
M:&UI8RD@<F5S:7-T86YC92!O9B!A('!A8VMA9V4@<W1U8B!S96-T:6]N+"!I
M;@I\(" @(" @(" @(" @(" @(" @(" @=&5R;7,@;V8@;VAM<R!P97(@=6YI
M="!L96YG=&@N"GP@(" @(" @(" @(" @36%T<FEX("!5<V4@;V8@=&AI<R!S
M=6)P87)A;65T97(@;65A;G,@=&AA="!T:&ES('!A8VMA9V4@<W1U8@I\(" @
M(" @(" @(" @(" @(" @(" @<V5C=&EO;G,@96QE8W1R:6-A;"!P87)A;65T
M97)S(&%R92!P<F5S96YT960@87,@<&%R="!O9@I\(" @(" @(" @(" @(" @
M(" @(" @82!C;W5P;&EN9R!M871R:7@N("!4:&ES('-U8G!A<F%M971E<B!D
M969I;F5S('1H92 *?" @(" @(" @(" @(" @(" @(" @(&YA;64@;V8@=&AE
M(&UA=')I>"X@1F]R(&5X86UP;&4@36%T<FEX/3-,:6Y3=')I<"!D969I;F5S
M( I\(" @(" @(" @(" @(" @(" @(" @82!C;W5P;&5D('-E8W1I;VXL('!R
M;V)A8FQY(&-O;G1A:6YI;F<@,R!S=')I<"!L:6YE<RX@(" @"GP@(" @(" @
M(" @(" @(" @(" @("!4:&4@9&%T82!F;W(@=&AE(&UA=')I>"!I<R!I;F-L
M=61E9" *?" @(" @(" @(" @(" @(" @(" @(&)E='=E96X@=&AE(%M-;V1E
M;"!$871A72];16YD($UO9&5L($1A=&%=(&ME>7=O<F0@<&%I<G,*?" @(" @
M(" @(" @(" @(" @(" @(&%S(&1E<V-R:6)E9"!B96QO=RX@( H*?" @(" @
M(" @(" @("!->%!I;D]R9&5R($EF('1H92!K97D@=V]R9"!-871R:7@@:7,@
M=7-E9"!I="!S:&]U;&0@8F4@9F]L;&]W960*?" @(" @(" @(" @(" @(" @
M(" @(" @(&)Y($UX4&EN3W)D97(@=VAI8V@@9&5S8W)I8F5S('1H92!2;W<@
M;W)D97)I;F<*?" @(" @(" @(" @(" @(" @(" @(" @(&]F('1H92!M871R
M:7@@9VEV96X@:6X@<&%R96YT:&5S:7,N"GP@(" @(" @(" @(" @(" @(" @
M(" @("!&;W(@(&5X86UP;&4@"GP@(" @(" @(" @(" @(" @(" @(" @("!-
M871R:7@],TQI;E-T<FEP($UX4&EN3W)D97(]*$$Q($$R($$S*0I\(" @(" @
M(" @(" @(" @(" @(" @(" @<W!E8VEF:65S(&$@,W@S(&UA=')I>"!N86UE
M9" S3&EN4W1R:7 @=VAO<V4@<F]W"GP@(" @(" @(" @(" @(" @(" @(" @
M("!O<F1E<FEN9R!C;W)R97-P;VYD<R!T;R!2;W<@,2 ](%!I;B!!,2P@"GP@
M(" @(" @(" @(" @(" @(" @(" @("!2;W<@,B ](%!I;B!!,B!A;F0@4F]W
M(#,@/2!0:6X@03,*? I\(" @(" @(" @(" @(%-P96-I9GEI;F<@82!L96YG
M=&@@;W(@3"]2+T,@=F%L=64@;V8@>F5R;R!I<R!A;&QO=V5D+B @268*?" @
M(" @(" @(" @("!,96X@/2 P(&ES('-P96-I9FEE9"P@=&AE;B!T:&4@3"]2
M+T,@=F%L=65S(&%R92!T:&4@=&]T86P*?" @(" @(" @(" @("!F;W(@=&AA
M="!S96-T:6]N+B @268@82!N;VXM>F5R;R!L96YG=&@@:7,@<W!E8VEF:65D
M+"!T:&5N"GP@(" @(" @(" @(" @=&AE('1O=&%L($PO4B]#(&9O<B!A('-E
M8W1I;VX@:7,@8V%L8W5L871E9"!B>2!M=6QT:7!L>6EN9R *?" @(" @(" @
M(" @("!T:&4@=F%L=64@;V8@=&AE($QE;B!S=6)P87)A;65T97(@8GD@=&AE
M('9A;'5E(&]F('1H92!,+ I\(" @(" @(" @(" @(%(@;W(@0R!S=6)P87)A
M;65T97(N"GP*?" @(" @(" @(" @("!5<VEN9R!4:&4@4W5B<&%R86UE=&5R
M<R!T;R!$97-C<FEB92!086-K86=E(%-T=6(@4V5C=&EO;G,Z"GP@(" @(" @
M(" @(" @16%C:"!S96-T:6]N(&1E<V-R:7!T:6]N(&UU<W0@8F5G:6X@=VET
M:"!T:&4@3&5N('-U8G!A<F%M971E<B!A;F0*?" @(" @(" @(" @("!E;F1S
M('=I=&@@=&AE('-L87-H("@O*2!C:&%R86-T97(N("!4:&4@=F%L=64@;V8@
M82!S=6(M"GP@(" @(" @(" @(" @<&%R86UE=&5R(&%N9"!T:&4@<W5B<&%R
M86UE=&5R(&ET<V5L9B!A<F4@<V5P87)A=&5D(&)Y(&%N(&5Q=6%L<PI\(" @
M(" @(" @(" @('-I9VX@*#TI.R!W:&ET97-P86-E(&%R;W5N9"!T:&4@97%U
M86QS('-I9VX@:7,@;W!T:6]N86PN("!!;&P@"GP@(" @(" @(" @(" @<&%C
M:V%G92!S='5B(&1E<V-R:7!T:6]N<R!M=7-T(&-O;G1A:6X@=&AE('-A;64@
M;G5M8F5R(&]F( I\(" @(" @(" @(" @('-E8W1I;VYS(&AO=V5V97(L(&$@
M<&%R=&EC=6QA<B!S96-T:6]N(&1E<V-R:7!T:6]N(&-A;B!C;VYT86EN( I\
M(" @(" @(" @(" @(&YO(&1A=&$@*&DN92X@=&AE(&1E<V-R:7!T:6]N(&ES
M(&=I=F5N(&%S("=,96X@/2 P("\G+B @4V5E('1H92 *?" @(" @(" @(" @
M("!E>&%M<&QE(&)E;&]W*2X@( I\"GP@(" @(" @(" @(" @3&5G86P@4W5B
M<&%R86UE=&5R($-O;6)I;F%T:6]N<SH*?" @(" @(" @(" @("!!*2!!('-I
M;F=L92!,96X@/2 P('-U8G!A<F%M971E<BP@9F]L;&]W960@8GD@82!S;&%S
M:"X*?" @(" @(" @(" @("!4:&4@:7,@=7-E9"!T;R!D97-C<FEB92!A('-E
M8W1I;VX@=VET:"!N;R!D871A+@I\"GP@(" @(" @(" @(" @0BD@($QE;B!A
M;F0@='=O($UA=')I>"!S=6)P87)A;65T97)S+"!F;VQL;W=E9"!B>2!A"GP@
M(" @(" @(" @(" @8F%C:W-L87-H+B!4:&4@3&5N('-U8G!A<F%M971E<B!S
M<&5C:69I97,@=&AE(&QE;F=T:"!O9B!T:&%T( I\(" @(" @(" @(" @('-E
M8W1I;VX@=VAI;&4@=&AE($UA=')I>"!S=6)P87)A;65T97(@:6YD:6-A=&5S
M('1H870@=&AI<R *?" @(" @(" @(" @("!S96-T:6]N(&]F('1H:7,@<&%C
M:V%G92!S='5B(&ES(&5L96-T<FEC86QL>2!C;W5P;&5D('1O('1H92 *?" @
M(" @(" @(" @("!C;W)R97-P;VYD:6YG("AS86UE(&YU;6)E<F5D*2!S96-T
M:6]N(&]F(&%N(&%D:F%C96YT('!A8VMA9V4@"GP@(" @(" @(" @(" @<W1U
M8B H;W(@<W1U8G,I(&%N9"!T:&4@8V]U<&QI;F<@=&5R;7,@87)E(&QI<W1E
M9"!I;B!A(&UA=')I> I\(" @(" @(" @(" @(&9O<FUA="X@(%1H92!M871R
M:7@@9&5S8W)I<'1I;VX@;75S="!I;F-L=61E(&)O=&@@=&AE("=S96QF)R *
M?" @(" @(" @(" @("!I;F1U8W1A;F-E+V-A<&%C:71A;F-E+W)E<VES=&%N
M8V4@*&%S(')E<75I<F5D*2!O9B!A('-E8W1I;VX@"GP@(" @(" @(" @(" @
M87,@=V5L;"!A<R!T:&4@;75T=6%L(&-O=7!L:6YG('1E<FUS+B @268@;VYE
M('-E8W1I;VX@:7,*?" @(" @(" @(" @("!D97-C<FEB960@=7-I;F<@=&AE
M('1H92!-871R:7@@<W5B<&%R86UE=&5R('1H96X@=&AE( I\(" @(" @(" @
M(" @(&-O<G)E<W!O;F1I;F<@*'-A;64@;G5M8F5R960I('-E8W1I;VYS(&]N
M($%,3"!O=&AE<B!P86-K86=E( I\(" @(" @(" @(" @('-T=6)S(&UU<W0@
M=7-E('1H92!-871R:7@@<W5B<&%R86UE=&5R+B *? I\(" @(" @(" @(" @
M($,I("!,96XL(&%N9"!O;F4@;W(@;6]R92!O9B!T:&4@3"P@4B!A;F0@0R!S
M=6)P87)A;65T97)S+B @268*?" @(" @(" @(" @("!T:&4@3&5N('-U8G!A
M<F%M971E<B!I<R!G:79E;B!A<R!Z97)O+"!T:&5N('1H92!,+U(O0R!S=6(M
M"GP@(" @(" @(" @(" @<&%R86UE=&5R<R!R97!R97-E;G0@;'5M<&5D(&5L
M96UE;G1S+B @268@=&AE('1H92!,96X@<W5B+0I\(" @(" @(" @(" @('!A
M<F%M971E<B!I<R!N;VXM>F5R;RP@=&AE;B!T:&4@3"]2+T,@<W5B<&%R86UE
M=&5R<R!R97!R97-E;G0*?" @(" @(" @(" @("!D:7-T<FEB=71E9"!E;&5M
M96YT<RX*? I\"GP@(" @(" @(" @(" @26X@=&AE(&5X86UP;&4@8F5L;W<@
M=&AE(&9I<G-T('-E8W1I;VX@:7,@82!L=6UP960@:6YD=6-T;W(L"GP@(" @
M(" @(" @(" @=&AE('-E8V]N9"!S96-T:6]N(&ES(&1E<V-R:6)E9"!U<VEN
M9R!A(#,M;&EN92!M871R:7@L(&%N9" *?" @(" @(" @(" @("!T:&4@=&AI
M<F0*?" @(" @(" @(" @("!S96-T:6]N(&ES(&UO9&5L960@=7-I;F<@9&ES
M=')I8G5T960@96QE;65N=',N("!0:6X@03,@<VAO=W,*?" @(" @(" @(" @
M("!A;B!E>&%M<&QE(&]F('-E8W1I;VYS('=I=&@@;F\@9&%T82X@(%!I;B!!
M,R!A;'-O('-H;W=S(&$@"GP@(" @(" @(" @(" @,FQI;F4@;6%T<FEX('-E
M8W1I;VX@8V]U<&QE9"!T;R!!-2$@4&EN<R!!-"!A;F0@034@:6QL=7-T<F%T
M90I\(" @(" @(" @(" @(&AO=R!A('-E8W1I;VX@9&5S8W)I<'1I;VX@8V%N
M(&)E(&)R;VME;B!A8W)O<W,@;75L=&EP;&4@;&EN97,*?" @(" @(" @(" @
M("!A;F0@:&]W(&5A8V@@<V5C=&EO;B!D97-C<FEP=&EO;B!I<R!D96QI;6ET
M960@8GD@=&AE('-L87-H+@I\+2TM+2TM+2TM+2TM+2TM+2TM+2TM+2TM+2TM
M+2TM+2TM+2TM+2TM+2TM+2TM+2TM+2TM+2TM+2TM+2TM+2TM+2TM+2TM+2TM
M+2TM+2T*6U!I;B!.=6UB97)="D$Q(" @3&5N(#T@,"!,/3$N,FX@+R!,96X@
M/2 Q+C,@36%T<FEX/3-L:6YE($UX4&EN3W)D97(]*$$Q($$R($$S*2 O( H@
M(" @($QE;CTP+C0W($P]."XS-6X@0STS+C,T<"!2/3 N,#$@+PI!,B @($QE
M;B ](# @3#TQ+C1N("\@3&5N(#T@,2XR($UA=')I>#TS;&EN92!->%!I;D]R
M9&5R/2A!,2!!,B!!,RDO( H@(" @($QE;CTP+C0W($P]-BXR,6X@0STS+C,T
M<"!2/3 N,#$@+PI!,R @($QE;B ](# @(" @(" @("\@3&5N(#T@,2XQ($UA
M=')I>#TS;&EN92!->%!I;D]R9&5R/2A!,2!!,B!!,RD@("\@"B @(" @3&5N
M(#T@," @36%T<FEX/3)L:6YE($UX4&EN3W)D97(]*$$S($$U*2 @(" @(" @
M(" @(" @(" @(" @(" @+PI!-" @($QE;B ](# @3#TQ+C)N("\@3&5N(#T@
M,2XP($P],FY(("\@3&5N/3 N-#<@3#TX+C,U;B *(" @("!#/3,N,S1P(%(]
M,"XP,2\*034@("!,96X@/2 P($P],2XR;B O(" *(" @("!,96X],2XR($UA
M=')I>#TR;&EN92!->%!I;D]R9&5R/2A!,R!!-2D@+R *(" @("!,96X],"XT
M-R!,/2 X+C,U;B!#/3,N,S1P(%(],"XP,2 O"GP*?" @("!.;W1E('1H870@
M=&AE(&%C='5A;"!L96YG=&@@9F]R(&5A8V@@<V5C=&EO;B!I<R!R97!O<G1E
M9"P@979E;B!F;W(*?" @("!T:&]S92!S96-T:6]N<R!T:&%T('5S92!T:&4@
836%T<FEX('-U8G!A<F%M971E<BX*? H*
 
end

From EGJJ77A@mail.prodigy.com  Thu Oct 19 11:13:06 1995
Return-Path: <EGJJ77A@mail.prodigy.com>
Received: from pimaia2w.prodigy.com by vhdl.vhdl.org (4.1/SMI-4.1/BARRNet)
	id AA08612; Thu, 19 Oct 95 11:13:06 PDT
Received: from mail.prodigy.com ([199.4.137.13]) by pimaia2w.prodigy.com (8.6.10/8.6.9) with SMTP id NAA30024; Thu, 19 Oct 1995 13:53:13 -0400
Date: Thu, 19 Oct 1995 13:40:56 EDT
From: EGJJ77A@prodigy.com (MR RONALD J CHRISTOPHER)
X-Mailer: PRODIGY Services Company Internet mailer [PIM 3.2-342.56]
Message-Id: <013.03202929.EGJJ77A@prodigy.com>
To: ibis@vhdl.org, roadmap-eii@cfi.org
Subject: Information on DIE, DIET, DCL, and EDIF PCB/MCM

-- [ From: Ron Christopher * EMC.Ver #2.10P ] --

I was asked to post information on DIE, DIET, DCL, and EDIF PCB/MCM to
the IBIS reflector.  These are proposed standards that contain
information that relate to processing the higher level package.

DIE:
DIE is DIE Information Exchange Format.  The specification states, "DIE
Format is a computer-sensible and human-readable interchange format for
information about unpackaged Integrated Circuits (ICs). . .  The DIE
format conveys the physical and functional characteristics of an
unpackaged die; that is, those characteristics needed for place & route,
thermal analysis, electrical signal analysis, power distribution design,
physical bonding, behavior, test, and timing analysis. . .  Die
specifically covered by the format are pre-diced die (wafer form), bare
die, and die that have been post-processed for pad attachment
mechanisms such as solder bump, wire bond, lead frame (TAB and Ribbon),
and Chips First."

DIE references IBIS for the IBIS information required for delay
calculation and signal integrity analysis.  DIE references VHDL and
maps the physical pads to VHDL pins for the functional information. 
DIE includes pad output driving capability at logic low level, pad
output driving capability at logic high level, and threshold voltages
required for testing and for voltage drop checking.

The specification states, "Passives, discretes, and Analog signal pin
electrical characteristics are not included in this draft.  Some
bonding styles (Beam Lead and Solder Ball may not be fully covered yet.
MCM Substrate test development support and timing information are not
yet included."  DIE does not include any physical characteristics of
the wire from the package lead down to the circuit.

The DIE specification is publicly available in several formats at
vhdl.org/pub/die/die1-0-3.*  The work was done under an ARPA contract,
and EIA (Patti Rusher) is attempting to find a way to get it completed.

DIET:
DIET is Die Information Exchange for Timing.  The DIET specification
states, "DIET Format is an unambiguous, EDA-tool processable, human-
readable medium for specifying and exchanging DC and AC timing
information such as setup, hold, and propagation delays about complex
IC components in either die or packaged form. . . The DIET Format
provides information about the external pin to pin timing
characteristics of complex digital or mixed-signal IC components -
there is no intent to represent timing information or functional
behavior about the internal gate level components or net list structure
of an IC.  Neither does the DIET Format speak to instance or design
specific timing information regarding the IC's external environment."

The timing relationships include six basic types: 
 - propagation delay - edge to value relationship
 - setup time - stable to edge relationship
 - hold time - edge to stable relationship
 - cycle time - edge to edge relationship
 - pulse width time - edge to edge relationship
 - skew time - edge to edge relationship.

DIET does include an internal timing point concept that supports static
timing with multiple clocks with one model.  It supports multiple
versions in one table.

DIET does not include any expressive capability.

The DIET specification is publicly available in several formats at
vhdl.org/pub/diet/latest/diet0-95.*  The work was done under an ARPA
contract, and EIA (Patti Rusher) is attempting to find a way to get it
completed.  DIET could be contained in DCL which would then include
expressive capability.

DCL:
DCL is Delay Calculator Language being proposed by CFI/OVI to meet the
following requirements:

 - Allow silicon foundries to describe delay equations for ASIC
libraries, and in a single way which can be used by any set of CAD
applications and vendors.

 - Allow CAD vendors to interface to delay calculation for specified
design elements using a single interface to the foundry supplied
equations.

 - Account for wire capacitance as well as gate capacitance.

 - Provide a Delay Language compiler which creates a compiled form of
the delay expression language, which when executed with a specific net
description, can calculate all necessary delay characteristics of the
net and associated gates.  This then provides the same set of delay
values to each vendor tool.

 - Provide a programming interface (PI) to a compiled form of delay
equations described in the delay equation expression language.

 - The calculation from the delay equations must be of high enough
performance to support both the batch calculation of all delays, and
the incremental calculation of individual nets within design
applications such as synthesis.  This calculation is to include both
pre-layout and post-layout phases of the design process.

 - Support transmission line analysis.

The specification under development is publicly available in several
forms at cfi.org/public/Cfi/Development/Projects/Alr/DCLLang10_date
where date may keep changing.  It is intended to be available in 1996.

EDIF PCB/MCM:
EDIF PCB/MCM 4.0.0 is an extension of EDIF to support all the physical
design detail of PCB boards, and MCM's.  It is planned to be balloted
in 1995.  The level 4.0.0 that includes MCM's will be available at the
end of October, 1995.  It will be available in Frame format with
special login and password similar to the OMF specification.  For
access contact Hilary Kahn at kahn@edif.org.


From jmf@cup.portal.com  Thu Oct 19 17:24:59 1995
Return-Path: <jmf@cup.portal.com>
Received: from nova.unix.portal.com by vhdl.vhdl.org (4.1/SMI-4.1/BARRNet)
	id AA09950; Thu, 19 Oct 95 17:24:59 PDT
Received: from hobo.online.portal.com (hobo.online.portal.com [156.151.5.5]) by nova.unix.portal.com (8.6.11/8.6.5) with ESMTP id RAA26413 for <ibis@vhdl.org>; Thu, 19 Oct 1995 17:16:39 -0700
From: jmf@cup.portal.com
Received: (pccop@localhost) by hobo.online.portal.com (8.6.10/8.6.5) id RAA10440 for ibis@vhdl.org; Thu, 19 Oct 1995 17:16:38 -0700
To: ibis@vhdl.org
Subject: unsubscribe
Lines: 1
Date: Thu, 19 Oct 95 17:16:38 PDT
Message-Id: <9510191716.1.10416@cup.portal.com>
X-Origin: The Portal System (TM)

Please unsubscribe jmf@cup.portal.com

From bob@icx.com  Fri Oct 20 15:15:19 1995
Return-Path: <bob@icx.com>
Received: from icx.com (icx.rain.com) by vhdl.vhdl.org (4.1/SMI-4.1/BARRNet)
	id AA19371; Fri, 20 Oct 95 15:15:19 PDT
Received: by icx.com (/\==/\ Smail3.1.28.1 #28.14)
	id <m0t6Pas-000FVkC@icx.com>; Fri, 20 Oct 95 15:07 PDT
Received: by icx.com (/\==/\ Smail3.1.28.1 #28.14)
	id <m0t6PdT-000GjSC@icx.com>; Fri, 20 Oct 95 15:09 PDT
Message-Id: <m0t6PdT-000GjSC@icx.com>
Date: Fri, 20 Oct 95 15:09 PDT
From: bob@icx.com ( Bob Ross)
To: ibis@vhdl.org
Subject: IBIS MEETING AGENDA 10/27/95

                       IBIS Open Forum Meeting Agenda 
                                for 10/27/95
 
                  Bridge Number    Reservation #   Passcode
                  (916) 356-9200   1-29704         4532338

 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                         Powell

      - Intros of New IBIS Participants, Meeting Quorum       Powell
      - Membership Update and Treasurers Report               Rusher/Powell
      - Review of Previous Meeting's Minutes (and ARs)        Ross
      - Miscellany/Announcements                              All
      - Press Updates                                         All
      - New Models Available, Library Update                  All
      - Opens for New Issues                                  All


 8:10 EIA IBIS Ratification                                             

      - EIA/ANSI Ratification Progress                        Ross/Rusher
      - Press Release Discussion                              Powell/Rusher

 
 8:20 Administrative and Project Discussions

      Face-to-Face meeting                                    Huq

      Web Project Update &                                    Huq
      Company Logos                                           Powell
 
      Model Usage Tracking on vhdl.org                        Huq/Steer

      Golden Parser 2.1 Status                                Powell/Ross
 
      S2IBIS 2.1 Status                                       Kumar/Steer
 
      Version 2.1 Cookbook and Overview                       Chrisafulli/Ross
      
      New Administrative Issues                               All


 9:00 Technical Discussions

      BIRD30.2 - Pin Programmable Buffer Strengths            Muranyi

      BIRD28.3+ - Matrix Name Enhancement proposal            Kumar/Peters

      EGG6 - CMOS and TTL Data                                Powell

      EGG7 - Connector/Cable Egg                              Ross

      DCL relationship, Roadmap timing, Other Standards       Christopher

      Physical Package Description Discussion                 Crisafulli

      New Technical Issues                                    All


 9:50 Wrap Up and Next Meetings Plans                         Powell

 9:55 Sign Off
 



From cyblta@taux01.nsc.com  Sun Oct 22 05:14:14 1995
Return-Path: <cyblta@taux01.nsc.com>
Received: from gatekeeper.nsc.com by vhdl.vhdl.org (4.1/SMI-4.1/BARRNet)
	id AA04802; Sun, 22 Oct 95 05:14:14 PDT
Received: from nsc.nsc.com by gatekeeper.nsc.com (5.65/fma-120691) with SMTP;
	id AA04093 for ibis@vhdl.org; Sun, 22 Oct 95 05:06:54 -0700
Received: from taux01.nsc.com by nsc.nsc.com (5.65/1.34) with SMTP
	id AA14538 for ibis@vhdl.org; Sun, 22 Oct 95 05:06:52 -0700
Received: from tasu03.nsc.com by taux01.nsc.com (4.1/SMI-4.1)
	id AA14608; Sun, 22 Oct 95 14:09:42 IST
Received: by tasu03.nsc.com (4.1/SMI-4.1)
	id AA14815; Sun, 22 Oct 95 14:09:40 IST
Date: Sun, 22 Oct 95 14:09:40 IST
From: cyblta@taux01.nsc.com (Yaron Blecher)
Message-Id: <9510221209.AA14815@tasu03.nsc.com>
To: ibis@vhdl.org
Subject: subscribe

subscribe

From micha@bard.cadlab.de  Mon Oct 23 02:15:24 1995
Return-Path: <micha@bard.cadlab.de>
Received: from boromir.cadlab.de by vhdl.vhdl.org (4.1/SMI-4.1/BARRNet)
	id AA09006; Mon, 23 Oct 95 02:15:24 PDT
Received: from bard.cadlab.de (micha@bard.cadlab.de [131.234.81.100]) by boromir.cadlab.de (8.6.9/8.6.5) with SMTP id JAA13190 for <ibis@vhdl.org>; Mon, 23 Oct 1995 09:45:12 +0100
From: Michael Gutzmann <micha@bard.cadlab.de>
Date: Mon, 23 Oct 95 09:45:11 +0100
Message-Id: <9510230845.AA04629@bard.cadlab.de>
Received: by bard.cadlab.de (4.1/12.71); Mon, 23 Oct 95 09:45:11 +0100
To: ibis@vhdl.org

Hello, IBISians !


I want to use IBIS for modeling of Ground/Power Noise of simultaneously
switching drivers. 
Spec version 2.1 can handle static V/I curves and Vout(t) curves
for a given load. If I've got this information then I am able to 
determine the rising/falling waveform of the output current Iout(t)
of a switching driver.

What I need for example to calculate the voltage drop over the
ground inductance L_gnd_pin (see below) is the contribution of every 
(simultaneously) switching driver to the current I_gnd(t) flowing 
through their common ground pin inductance (if I assume for
simplification that the inductance of the ground path is caused only
by that ground pin).

                         o PWR
                         | 
                         |
                         C
                         C L_pwr_pin
                         C
                         |
                         |
                         V I_pwr(t)
       I_pwr_1(t)        |                      I_pwr_n(t)
                         |
     -----<--------------*-------------  -  -  ----->---
     |                   |                             |
     |                   V I_pwr_2(t)                  |
     |                   |                             |
----------          ----------                    ----------
|        | Iout_1(t)|        |  Iout_2(t)         |        | Iout_n(t)
|Driver_1|          |Driver_2|                    |Driver_n| 
|        |--->-|    |        |--->--|             |        |--->--|
|        |     |    |        |      |             |        |      |
----------    ---   ----------     ---            ----------     ---
     |        --- CL_1   |         --- CL_2            |    CL_n ---
     |         |         |          |                  |          |
     |         |         |          |                  |          |
     |        ---        |         ---                 |         ---
     |                   |                             |
     V I_gnd_1(t)        V I_gnd_2(t)                  V I_gnd_n(t)
     |                   |                             |
     |                   |                             |
     --------------------*--------------  -  -  --------
                         |
                         |
                         V I_gnd(t)
                         |
                         C
                         C L_gnd_pin
                         C
                         |
                         |
                        ---

It would be useful for Ground/Power Noise calculations to have the
currents of the internal ground/power path of every driver 
I_gnd_1(t)/I_pwr_1(t) ... I_gnd_n(t)/I_pwr_n(t) with respect to
the corresponding Vout(t) curves for specified loads.

Unfortunately it is not possible to describe these ground/power path
currents with current IBIS format in my opinion. I'm quite aware
of the fact that this request perhaps contradicts the basic 
concept of IBIS because these internal ground/power path currents are
not measurable from outside of the package.

But at my point of view I don't see any other way for an
efficient ground (power) noise analysis.

However, what do you think about the opportunities to model 
power/ground noise and the resulting switching noise at the
outputs of active/quiescent output buffers by using present
or future IBIS format ?

Any comments to that problem will be appreciated.


Thank you very much in advance

Michael Gutzmann

Cadlab
Group Analog System Engineering
Joint R&D Institute
University of Paderborn
Siemens Nixdorf Informationssysteme AG
Fuerstenallee 7
33102 Paderborn
Germany

phone: +49-5251-60-6164
fax  : +49-5251-60-6155
e-mail: micha@cadlab.de



From micha@bard.cadlab.de  Mon Oct 23 03:38:00 1995
Return-Path: <micha@bard.cadlab.de>
Received: from boromir.cadlab.de by vhdl.vhdl.org (4.1/SMI-4.1/BARRNet)
	id AA09287; Mon, 23 Oct 95 03:38:00 PDT
Received: from bard.cadlab.de (micha@bard.cadlab.de [131.234.81.100]) by boromir.cadlab.de (8.6.9/8.6.5) with SMTP id LAA14166 for <ibis@vhdl.org>; Mon, 23 Oct 1995 11:30:29 +0100
From: Michael Gutzmann <micha@bard.cadlab.de>
Date: Mon, 23 Oct 95 11:30:27 +0100
Message-Id: <9510231030.AA04796@bard.cadlab.de>
Received: by bard.cadlab.de (4.1/12.71); Mon, 23 Oct 95 11:30:27 +0100
To: ibis@vhdl.org
Subject: Ground/Power Noise modeling of sim switch outputs

Hello, IBISians !

(Sorry, but I've forgotten to name a subject for posting my
 mail. Therefore I sent this message once again. The content is
 the same as in my first mail.)

I want to use IBIS for modeling of Ground/Power Noise of simultaneously
switching drivers. 
Spec version 2.1 can handle static V/I curves and Vout(t) curves
for a given load. If I've got this information then I am able to 
determine the rising/falling waveform of the output current Iout(t)
of a switching driver.

What I need for example to calculate the voltage drop over the
ground inductance L_gnd_pin (see below) is the contribution of every 
(simultaneously) switching driver to the current I_gnd(t) flowing 
through their common ground pin inductance (if I assume for
simplification that the inductance of the ground path is caused only
by that ground pin).

                         o PWR
                         | 
                         |
                         C
                         C L_pwr_pin
                         C
                         |
                         |
                         V I_pwr(t)
       I_pwr_1(t)        |                      I_pwr_n(t)
                         |
     -----<--------------*-------------  -  -  ----->---
     |                   |                             |
     |                   V I_pwr_2(t)                  |
     |                   |                             |
----------          ----------                    ----------
|        | Iout_1(t)|        |  Iout_2(t)         |        | Iout_n(t)
|Driver_1|          |Driver_2|                    |Driver_n| 
|        |--->-|    |        |--->--|             |        |--->--|
|        |     |    |        |      |             |        |      |
----------    ---   ----------     ---            ----------     ---
     |        --- CL_1   |         --- CL_2            |    CL_n ---
     |         |         |          |                  |          |
     |         |         |          |                  |          |
     |        ---        |         ---                 |         ---
     |                   |                             |
     V I_gnd_1(t)        V I_gnd_2(t)                  V I_gnd_n(t)
     |                   |                             |
     |                   |                             |
     --------------------*--------------  -  -  --------
                         |
                         |
                         V I_gnd(t)
                         |
                         C
                         C L_gnd_pin
                         C
                         |
                         |
                        ---

It would be useful for Ground/Power Noise calculations to have the
currents of the internal ground/power path of every driver 
I_gnd_1(t)/I_pwr_1(t) ... I_gnd_n(t)/I_pwr_n(t) with respect to
the corresponding Vout(t) curves for specified loads.

Unfortunately it is not possible to describe these ground/power path
currents with current IBIS format in my opinion. I'm quite aware
of the fact that this request perhaps contradicts the basic 
concept of IBIS because these internal ground/power path currents are
not measurable from outside of the package.

But at my point of view I don't see any other way for an
efficient ground (power) noise analysis.

However, what do you think about the opportunities to model 
power/ground noise and the resulting switching noise at the
outputs of active/quiescent output buffers by using present
or future IBIS format ?

Any comments to that problem will be appreciated.


Thank you very much in advance

Michael Gutzmann

Cadlab
Group Analog System Engineering
Joint R&D Institute
University of Paderborn
Siemens Nixdorf Informationssysteme AG
Fuerstenallee 7
33102 Paderborn
Germany

phone: +49-5251-60-6164
fax  : +49-5251-60-6155
e-mail: micha@cadlab.de



From bob@icx.com  Tue Oct 24 10:56:52 1995
Return-Path: <bob@icx.com>
Received: from icx.com (icx.rain.com) by vhdl.vhdl.org (4.1/SMI-4.1/BARRNet)
	id AA27132; Tue, 24 Oct 95 10:56:52 PDT
Received: by icx.com (/\==/\ Smail3.1.28.1 #28.14)
	id <m0t7nRe-000FVYC@icx.com>; Tue, 24 Oct 95 10:47 PDT
Received: by icx.com (/\==/\ Smail3.1.28.1 #28.14)
	id <m0t7nUD-000GjSC@icx.com>; Tue, 24 Oct 95 10:50 PDT
Message-Id: <m0t7nUD-000GjSC@icx.com>
Date: Tue, 24 Oct 95 10:50 PDT
From: bob@icx.com ( Bob Ross)
To: ibis@vhdl.org
Subject: IBISCHK2 EXECUTABLES
Cc: jonp@qdt.com

To IBISians:

The IBISCHK2 executables are available for various machines, temporarily under
/pub/ibis/ibischk2.  The makelog files are also included.  Please check these
executables and report any problems to ibis@vhdl.org or jonp@qdt.com or
bob@icx.com.

The last Beta version of ibischk2.exe for DOS is also available.

Thanks to Jon Powell for generating these executables.

Bob Ross
Interconnectix, Inc.

From medtron!relay.medtronic.com!hsin-huei.lin@uunet.uu.net  Tue Oct 24 12:42:42 1995
Return-Path: <medtron!relay.medtronic.com!hsin-huei.lin@uunet.uu.net>
Received: from relay5.UU.NET by vhdl.vhdl.org (4.1/SMI-4.1/BARRNet)
	id AA28055; Tue, 24 Oct 95 12:42:42 PDT
Received: from uucp4.UU.NET by relay5.UU.NET with SMTP 
	id QQzmwk23132; Tue, 24 Oct 1995 15:35:22 -0400 (EDT)
Received: from medtron.UUCP by uucp4.UU.NET with UUCP/RMAIL
        ; Tue, 24 Oct 1995 15:35:22 -0400
Received: from medtron.medtronic.COM by relay.medtronic.com with SMTP id AA09682
  (5.65c/IDA-1.4.4 for <ibis@vhdl.org>); Tue, 24 Oct 1995 14:32:58 -0500
Received: from mspeos.cis.corp.medtronic.COM (eos.cis.corp.medtronic.COM) by medtron.medtronic.COM with SMTP id AA09678
  (5.65c/IDA-1.4.4 for <ibis@vhdl.org>); Tue, 24 Oct 1995 14:32:57 -0500
Received: from eos.cis.corp.medtronic.COM by mspeos.cis.corp.medtronic.COM (5.x/SMI-SVR4)
	id AA18870; Tue, 24 Oct 1995 14:29:20 -0500
Received: from MSPEOS-Message_Server by eos.cis.corp.medtronic.COM
	with Novell_GroupWise; Tue, 24 Oct 1995 14:29:20 -0500
Message-Id: <s08cf840.002@eos.cis.corp.medtronic.COM>
X-Mailer: Novell GroupWise 4.1
Date: Tue, 24 Oct 1995 14:30:45 -0500
From: Hsin-Huei Lin <hsin-huei.lin@medtronic.com>
To: ibis@vhdl.org
Subject:  How to calculate mutual capacitance through multiple layers

Hi,
	I need to figure out the mutual capacitance between two nets on a
hybrid design that go through various layers in the substrate. The software
tool I use can only provide the capacitance on a per layer basis. Does
anyone know how I can calculate the total mutual capacitance from the
individual data values? Do I need to include the mutual capacitance between
two layers of the same net and between two layers of two nets? Thank you in
advance for your reply!

Hsin-Huei Lin
Medtronic, Inc.


From bob@icx.com  Tue Oct 24 16:02:30 1995
Return-Path: <bob@icx.com>
Received: from icx.com (icx.rain.com) by vhdl.vhdl.org (4.1/SMI-4.1/BARRNet)
	id AA28926; Tue, 24 Oct 95 16:02:30 PDT
Received: by icx.com (/\==/\ Smail3.1.28.1 #28.14)
	id <m0t7ruY-000FVgC@icx.com>; Tue, 24 Oct 95 15:33 PDT
Received: by icx.com (/\==/\ Smail3.1.28.1 #28.14)
	id <m0t7rxD-000GjSC@icx.com>; Tue, 24 Oct 95 15:36 PDT
Message-Id: <m0t7rxD-000GjSC@icx.com>
Date: Tue, 24 Oct 95 15:36 PDT
From: bob@icx.com ( Bob Ross)
To: ibis@vhdl.org, micha@bard.cadlab.de
Subject: Re:  Ground/Power Noise modeling of sim switch outputs

Michael:

I tend to agree with your assessment that knowing I_pwr_n(t) and I_gnd_n(t) 
obtained under the test load condition will give a more accurate 
Simutaneous Switching Output analysis.  There may be some feedback
interactions when switching several outputs which may cause the total
power and ground currents to be different than the sum of the components
found individually.  However, this approach should still be reasonably 
accurate under the test load conditions.

Presently, IBIS can be used to estimate the currents based on assuming
the Pullup table provides currents from the Power Bus, and the
Pulldown table provides currents from the Ground Bus.  The currents
that are provided by each BUS into the test loads during the
low-to-high and high-to-low transitions depend on the simulator
switching or blending algorithm with respect to the Pullup and Pulldown
tables.  So this approach can only be approximate.  The IBIS format does
not give any more details about internal dynanic impedances which would
effect the current distributions.

If providing I_pwr_n(t) and I_gnd_n(t) tables gives sufficient information,
the IBIS format could be easily extended using syntax similar to [Rising 
Waveform] and [Falling Waveform] to provide this data.  However, I am
wondering how this information can be accurately applied in real loading
situations (not just the test load case) to simulate actual power and ground
bounce noise.  Also, what are the best test loads?

Bob Ross,
Interconnectix, Inc.


> Hello, IBISians !

> (Sorry, but I've forgotten to name a subject for posting my
>  mail. Therefore I sent this message once again. The content is
>  the same as in my first mail.)

> I want to use IBIS for modeling of Ground/Power Noise of simultaneously
> switching drivers. 
> Spec version 2.1 can handle static V/I curves and Vout(t) curves
> for a given load. If I've got this information then I am able to 
> determine the rising/falling waveform of the output current Iout(t)
> of a switching driver.

> What I need for example to calculate the voltage drop over the
> ground inductance L_gnd_pin (see below) is the contribution of every 
> (simultaneously) switching driver to the current I_gnd(t) flowing 
> through their common ground pin inductance (if I assume for
> simplification that the inductance of the ground path is caused only
> by that ground pin).

>                          o PWR
>                          | 
>                          |
>                          C
>                          C L_pwr_pin
>                          C
>                          |
>                          |
>                          V I_pwr(t)
>        I_pwr_1(t)        |                      I_pwr_n(t)
>                          |
>      -----<--------------*-------------  -  -  ----->---
>      |                   |                             |
>      |                   V I_pwr_2(t)                  |
>      |                   |                             |
> ----------          ----------                    ----------
> |        | Iout_1(t)|        |  Iout_2(t)         |        | Iout_n(t)
> |Driver_1|          |Driver_2|                    |Driver_n| 
> |        |--->-|    |        |--->--|             |        |--->--|
> |        |     |    |        |      |             |        |      |
> ----------    ---   ----------     ---            ----------     ---
>      |        --- CL_1   |         --- CL_2            |    CL_n ---
>      |         |         |          |                  |          |
>      |         |         |          |                  |          |
>      |        ---        |         ---                 |         ---
>      |                   |                             |
>      V I_gnd_1(t)        V I_gnd_2(t)                  V I_gnd_n(t)
>      |                   |                             |
>      |                   |                             |
>      --------------------*--------------  -  -  --------
>                          |
>                          |
>                          V I_gnd(t)
>                          |
>                          C
>                          C L_gnd_pin
>                          C
>                          |
>                          |
>                         ---

> It would be useful for Ground/Power Noise calculations to have the
> currents of the internal ground/power path of every driver 
> I_gnd_1(t)/I_pwr_1(t) ... I_gnd_n(t)/I_pwr_n(t) with respect to
> the corresponding Vout(t) curves for specified loads.

> Unfortunately it is not possible to describe these ground/power path
> currents with current IBIS format in my opinion. I'm quite aware
> of the fact that this request perhaps contradicts the basic 
> concept of IBIS because these internal ground/power path currents are
> not measurable from outside of the package.

> But at my point of view I don't see any other way for an
> efficient ground (power) noise analysis.

> However, what do you think about the opportunities to model 
> power/ground noise and the resulting switching noise at the
> outputs of active/quiescent output buffers by using present
> or future IBIS format ?

> Any comments to that problem will be appreciated.


> Thank you very much in advance

> Michael Gutzmann

> Cadlab
> Group Analog System Engineering
> Joint R&D Institute
> University of Paderborn
> Siemens Nixdorf Informationssysteme AG
> Fuerstenallee 7
> 33102 Paderborn
> Germany

> phone: +49-5251-60-6164
> fax  : +49-5251-60-6155
> e-mail: micha@cadlab.de





From Arpad_Muranyi@ccm.fm.intel.com  Tue Oct 24 16:15:59 1995
Return-Path: <Arpad_Muranyi@ccm.fm.intel.com>
Received: from ormail.intel.com by vhdl.vhdl.org (4.1/SMI-4.1/BARRNet)
	id AA28976; Tue, 24 Oct 95 16:15:59 PDT
Received: from relay.jf.intel.com by ormail.intel.com with smtp
	(Smail3.1.28.1 #7) id m0t7sSP-000UhlC; Tue, 24 Oct 95 16:08 PDT
Received: from ccm.hf.intel.com by relay.jf.intel.com
	(Smail3.1.28.1 #2) id m0t7sSN-000twWC; Tue, 24 Oct 95 16:08 PDT
Received: by ccm.hf.intel.com (ccmgate 3.2 #3) Tue, 24 Oct 95 16:08:31 PDT
Date: Tue, 24 Oct 95 16:00:00 PDT
From: Arpad Muranyi <Arpad_Muranyi@ccm.fm.intel.com>
Message-Id: <Tue, 24 Oct 95 16:08:19 PDT_3@ccm.hf.intel.com>
To: ibis@vhdl.org
Subject: BIRD30.2

BIRD ID#:      30.2
ISSUE TITLE:   Programmable buffers in IBIS models
REQUESTER:     Arpad Muranyi

DATE SUBMITTED:                       10-24-95
DATE ACCEPTED BY IBIS OPEN FORUM:     Pending

******************************************************************************
******************************************************************************

STATEMENT OF THE ISSUE:

The current IBIS specification (2.1) does not provide a selection mechanism
for buffers which can change characteristics based on configuration options in
a component (programmable buffers).  This BIRD is being written to provide a
solution to this problem.  Using this feature of the IBIS models simulator
tools can implement a mode selection user interface for programmable buffers.

******************************************************************************

STATEMENT OF THE RESOLVED SPECIFICATIONS:

A new keyword shall be introduced in the IBIS specification to provide a user
friendly buffer mode selection mechanism for components which use programmable
buffers.  The proposed keyword [Model selector] shall have a unique model
selector name on its right with the same syntax rules which apply to the model
name used with the [Model] keyword.

The model selector name is used in the [Pin] list in place of the buffer name
for pins which have programmable buffers.  Under the [Model selector] keyword
a list of those model names should appear which can be used by the pin
referencing this model selector name.  The first entry in the list is
considered to be the default [Model].  To help the user of the simulator tool
to make an intelligent choice, a description must appear on the right of each
of the model names in this list.  The description field can have multiple
words as in free flowing text, but shall not extend beyond the 80 character
line length limitation.

==============================================================================
|     Keyword:  [Model selector] 
|    Required:  No.
| Description:  Used to pick a [Model] from a list of [Model]s for a pin which 
|               uses a programmable buffer.
|  Sub-Params:  None.
| Usage Rules:  A programmable buffer must have an individual [Model] section
|               for each one of its modes used in the .ibs file.  The names of
|               these [Models] must be unique and can be listed under the
|               [Model selector] keyword and/or pin list.  The name of the
|               [Model selector] keyword must match the corresponding model
|               name listed under the [Pin] keyword and must not contain more
|               than 20 characters.  A .ibs file must contain enough [Model
|               selector] keywords to cover all of the model selector names
|               specified under the [Pin] keyword.
|
|               The section under the [Model selector] keyword must have two
|               fields.  The two fields must be separated by at least one
|               space or tab character.  However, the use of tab characters is
|               not recommended in general.  The first field lists the [Model]
|               name (up to 20 characters long).  The second field contains a
|               short description of the [Model] shown in the first field. 
|               The contents and format of this description is not
|               standardized, however it shall be limited in length so that
|               none of the descriptions exceed the 80-character length of the
|               line that it started on. The purpose of the descriptions is to
|               aid the user of the simulator tool in making intelligent
|               buffer mode selections and it can be used by the simulator
|               tool in a user interface dialog box as the bases of an
|               interactive buffer selection mechanism.
|
|               The first entry under the [Model selector] keyword shall be
|               considered the default by the simulator tool for all those
|               pins which call this [Model selector].
|
|               The operation of this selection mechanism implies that a group
|               of pins which use the same programmable buffer (i.e. model
|               selector name) will be switched together from one [Model] to
|               another.  Therefore, if two groups of pins, for example an
|               address bus and a data bus, use the same programmable buffer,
|               and the user must have the capability to configure them
|               independently, one can use two [Model selector] keywords with
|               unique names and the same list of [Model] keywords; however,
|               the usage of the [Model selector] is not limited to these
|               examples.  Many other combinations are possible.
|
|
[Pin]   signal_name     model_name      R_pin   L_pin   C_pin
|
  1     RAS0#           Progbuffer1     200.0m  5.0nH   2.0pF
  2     EN1#            Input1          NA      6.3nH   NA
  3     A0              3-state
  4     D0              Progbuffer2
  5     D1              Progbuffer2     320.0m  3.1nH   2.2pF
  6     D2              Progbuffer2
  7     RD#             Input2          310.0m  3.0nH   2.0pF
|  .
|  .
|  .
  18     Vcc3            POWER
| 
|
[Model selector]        Progbuffer1
|
ABCD0123456789ABCDE0 2 mA buffer  without slew rate control
ABCD0123456789ABCDE1 4 mA buffer  without slew rate control
ABCD0123456789ABCDE2 6 mA buffer  without slew rate control
ABCD0123456789ABCDE3 4 mA buffer  with slew rate control
ABCD0123456789ABCDE4 6 mA buffer  with slew rate control
|
[Model selector]        Progbuffer2
|
ABCD0123456789ABCDE0  2 mA buffer  without slew rate control
ABCD0123456789ABCDE3 16 mA buffer  without slew rate control
ABCD0123456789ABCDE4  6 mA buffer  with slew rate control
ABCD0123456789ABCDE5  8 mA buffer  with slew rate control
ABCD0123456789ABCDE6 10 mA buffer  with slew rate control
******************************************************************************

ANALYSIS PATH/DATA THAT LED TO SPECIFICATION:

Problem statement

Some components have programmable I/O buffers which can be configured for
different operating modes.  Their strength or slew rate (and maybe other
characteristics) can be changed during operation by some mechanism.  Currently,
the IBIS buffer modeling syntax provides keywords to describe a buffer model
in only one configuration or mode.  Even though there are ways to work around
this problem in the present form of IBIS, there is a definite need to provide
an easier and more user friendly selection mechanism for the various
configuration modes of programmable buffers.

Possible solutions

(1)  Currently it is NOT illegal to have more [Model] keywords in the IBIS
models than what the pin list section calls for.  Therefore, the writer of an
IBIS model can make as many [Model] sections as many are needed to describe
the various modes of the programmable buffers.  The user of the IBIS model can
change the model names of the programmable buffers in the [Pin] list section
with a text editor to select the desired buffer mode.  Instructions about
these edits can be placed in the Notes section and/or behind the comment
character for the user.  The main problem with this method is that it requires
tedious manual editing of the IBIS file.

(2)  A slightly different solution would use the same amount of [Model]
sections as described above, but repeat each pin description in the [Pin] list
as many times as many configurations a buffer associated with that pin has.
This method is not allowed in the current IBIS specification, but could be
made to work if the repeated pin descriptions are preceded with a comment
character.  This way the user could uncomment the line(s) which contain the
model name with the desired buffer mode.  This editing is much less tedious
and error prone than the one described in (1) above, but it can be cumbersome.
If the repeated pin description was legal in IBIS without the use of the
comment characters, the simulation tool could pick up the various model
choices from the [Pin] list section and provide a dialog box showing a list of
the available buffer modes for that pin.  The main problem with this method is
that the pin list can grow very long due to the repetitions.

(3)  Use #Define syntax to compile the IBIS model beforehand with the proper
buffers based on a model with multiple choices.  There are various C tools
that can do this.  One issue is if models can be changed dynamically such as
might be done to optimize a driver for a certain net.  This method has the
advantage that it does not require a new keyword, therefore it can be used
immediately.  However, it requires an extra compilation step before the IBIS
model can be used.  This contradicts one of the main goals of the IBIS
specification which was to provide simulation tools with models which can be
used directly.  This method could be used as an interim solution until the
new keywords are defined in the next IBIS revision.

(4)  A similar method to the one described in the STATEMENT OF THE RESOLVED
SPECIFICATIONS section would introduce a new keyword or sub parameter to be
used under the [Model] keyword.  This means that a [Model] could have many
complete sets of I-V and V-t curves which describe the various operating modes
of the buffer.  For example, one set of keywords describing a buffer in one
mode could come after the sub-parameter called [mode1], the next set of
keywords describing the buffer in another mode could reside under the
sub-parameter called [mode2], and so on, till all of the modes of the buffer
are characterized.  The default buffer could be defined with another
sub-parameter, such as Default.  The only difference between this method and
the suggested one in the main section of this document is that the selection
mechanism is inside the [Model] keyword and not outside.  However, this minor
difference imposes some limitations and might make an IBIS file unnecessarily
larger.

******************************************************************************

ANY OTHER BACKGROUND INFORMATION:

Based on the IBIS Open Forum discussions, two slight modifications were made to
the original BIRD issued as BIRD30.  One of the changes was the removal of the
sub-parameter Default and making the first entry in the [Model] list the
default.  The other change was the addition of a second column which contains
a description for each [Model] to be used in the user interface of the
simulation tools.  The original BIRD30 became BIRD30.1 with these changes.

Based on further discussions in the IBIS Open Forum, it was requested that it
should be allowed to have multi word (free flowing) text in the description
field of the entries under the [Model selector].  BIRD30.2 was submitted with 
this modification.

******************************************************************************


From huq@rockie.nsc.com  Tue Oct 24 16:45:09 1995
Return-Path: <huq@rockie.nsc.com>
Received: from gatekeeper.nsc.com by vhdl.vhdl.org (4.1/SMI-4.1/BARRNet)
	id AA29075; Tue, 24 Oct 95 16:45:09 PDT
Received: from nsc.nsc.com by gatekeeper.nsc.com (5.65/fma-120691) with SMTP;
	id AA18761 for ibis@vhdl.org; Tue, 24 Oct 95 16:37:48 -0700
Received: from lightning-gw.nsc.com by nsc.nsc.com (5.65/1.34) with SMTP
	id AA08463 for ibis@vhdl.org; Tue, 24 Oct 95 16:37:47 -0700
Received: from kural by rockie.nsc.com (4.1/SMI-4.1)
	id AA04794; Tue, 24 Oct 95 16:38:05 PDT
Date: Tue, 24 Oct 95 16:38:05 PDT
From: huq@rockie.nsc.com (Syed Huq)
Message-Id: <9510242338.AA04794@rockie.nsc.com>
To: ibis@vhdl.org
Subject: Face to Face 1996 

IBIS gurus,

The next EIA/IBIS face to face meeting will be held at
National Semiconductor, Santa Clara, CA and I am trying
to compile your inputs on preferred dates.

	"Monday Jan 29th" or "Friday Feb2nd"

This will fall right before or after "DesignSuperCON'96"
being held in Santa Clara, CA.

A lot of you have already responded to me and thanks for
your inputs.

If you have a preference, pls let me know...

Regards,
Syed
National Semiconductor

From speters@ichips.intel.com  Wed Oct 25 17:29:24 1995
Return-Path: <speters@ichips.intel.com>
Received: from hermes.intel.com by vhdl.vhdl.org (4.1/SMI-4.1/BARRNet)
	id AA09842; Wed, 25 Oct 95 17:29:24 PDT
Received: from ichips.intel.com by hermes.intel.com (5.65/10.0i); Wed, 25 Oct 95 17:21:29 -0700
Received: from xtg801 by ichips.intel.com (5.64+/10.0i); Wed, 25 Oct 95 17:20:54 -0700
Received: from localhost by xtg801.intel.com (4.1/10.0i); Wed, 25 Oct 95 17:20:53 PDT
Message-Id: <9510260020.AA05490@xtg801.intel.com>
To: cpk@cadence.com
Cc: ibis@vhdl.org
Subject: Expanded Package Models
Date: Wed, 25 Oct 1995 17:20:52 -0700
From: Stephen Peters <speters@ichips.intel.com>


Hello Kumar, and fellow IBISans:

     Thanks for the clarification.  In your points below, you state
point 1 as follows:

"1. Remove the restriction that only adjacent etch can be coupled"

     I'm not sure if this is what you had in mind, but the topology below
can be described by breaking it into the appropriate sections and giving 
each section its own matrix.  In the
section where the the etch is (top to bottom) pin2, pin3, pin4 and pin1
the matix still lists explicitly the elements that couple.  Likewise for the 
section where the pin order (top to bottom) is pin3, pin2, pin4 and pin1 --
the coupling between elements is explicitly specified.  What I am saying
is that one can go thru the matrix for a section and, for any given pin,
pull out only those that couple to it and build a small matrix per pin.


  pin1 ------------+     +----------------------  
  pin2 ------------|-----|----------------------
  pin3 ------------|-----+  +-------------------
  pin4 ------------|--------|-------------------
                   +--------+



     As far as having one section couple to another and having different
numbers of sections per pin: Great!  However, I do not think this is
an extention to the current package proposal.  What you propose is (to me
anyway) a starting point for describing MCM/SIMMs.  I also think that 
there needs to be some kind of net ordering or topological description 
file that goes along with the matrix data and not just a simple "section"
notation.  There needs to be a way to associate a matrix with a particular,
arbirary group/area/configuration of traces (that is sort of what the
section concept is about -- only in that case the topology was fixed to be
a bunch of elements in series).  At any rate, that is my feeling.  I really
look forward to discussing this with everyone Friday.

           Regards,
           Stephen Peters
           Intel Corp.



Hello:

Sorry I sent the original proposal (enahncement to stephen's package
 model enhancement (BIRD 28.3)!!) only to Stephen. The thrust of  my attempt
 is  to

1. Remove the restriction that only adjacent etch can be coupled

2. Remove the restriction that in order to use coupling the adjacent etch
 should have the same number of sections.

It is my hope these two modifications will make it possible to describe
 any kind of packages with arbitrary coupling between etch sections.
 No special restrictions on etch routing (like expecting adjacent pins to
 have adjacent etches) will be imposed.

I am attaching my original correspondence to Stephen

> 
> 
> Hello Kumar, and Fellow IBISans:
> 
>      Thank you for taking the time to write up your proposal.  I do
> have a couple of questions.  First, in your example, did you really
> mean for section #3 of pin A3 to couple to section --> #2 <-- of pin A5
> or section #3 of Pin A5.
> 
> ---------------------- your example
> 
> A1  Len = 0 L=1.2n /  Len= 1.2 Matrix=3line MxPinOrder=(A1 A2 A3) /
>     Len = 0.47 L=8.35n C=3.34p R=0.01 /
> A2  Len = 0 L=1.4n /  Len= 1.2 Matrix=3line MxPinOrder=(A1 A2 A3) /
>     Len = 0.47 L=8.35n C=3.34p R=0.01 /
> A3  Len = 0 L=1.4n /  Len= 1.2 Matrix=3line MxPinOrder=(A1 A2 A3) /
>     Len = 0 Matrix=2line MxPinOrder=(A3 A5) /
> A4  Len = 0 L=1.2n / Len = 1.0 L=2nH / Len=0.47 L=8.35
>     C=3.34p R=0.01/
> A5  Len = 0 L=1.2n /
>     Len = 0 Matrix=2line MxPinOrder=(A3 A5) /
>     Len = 0.47 L=8.35n C=3.34p R=0.01 /
> 

Yes. I wanted to show how section 2 of pin 2 is coupled to section 2 of pin 3 
and section 3 of pin3 is coupled to section 2 of pin 5!! The use of a matrix
 name and an explicit pin order makes this description possible.

> ---------------------
>      Second, it is not obvious to me what extra functionality
> or problem you are trying to address by adding the matrix names and the
> MxPinOrder keywords.  In your example above you want to show coupling
> between pins A1, A2 and A3, and also A3 coupling to A5.  This can be
> done by using the sparse matrix format as follows (using a capacitance
> matrix for illustration):
> 
> [Capacitance Matrix]  Sparse_matrix
> [Row] 1
> 1    xxpF
> 2    yypF
> 3    zzpF
> [Row] 2
> 2    aapF
> 3    zzpF
> [Row] 3
> 3    bbpF
> 5    ccpF
> [Row] 4
> 4    anothervaluepF
> .
> .
> .
> [Row] 5
> 5    stillanothervaluepF
> .
> .
> .
> and so on
> 
>      I get the feeling I am missing something in your explanation/example.
> Please enlighten me.
> 
>               Best Regards,
>               Stephen Peters
>               Intel Corp.
> 
The matrix description in the package section is meant to describe complete
 packages and the pin order includes ALL the package pins. The proposed matrix
 describing etch coupling can be arbitrarily small or large. The pins to the
 corresponding to the matrices are explicitly stated in the pin order.
----------
X-Sun-Data-Type: mail-file
X-Sun-Data-Description: mail-file
X-Sun-Data-Name: enh28.3
X-Sun-Encoding-Info: uuencode
X-Sun-Content-Lines: 189

begin 600 enh28.3
M1G)O;2!C<&L@5'5E($]C=" Q," Q.3HP,CHU," Q.3DU"E)E='5R;BU0871H
M.B \8W!K/@I&<F]M.B!C<&L@*$,N($MU;6%R*0I4;SH@<W!E=&5R<T!I8VAI
M<',N:6YT96PN8V]M"E-U8FIE8W0Z(&5N:&%N8V5D('!A8VMA9V4@;6]D96QS
M("AU<&1A=&4@=&\@0DE%1" R."XS*0I#8SH@8W!K"D-O;G1E;G0M3&5N9W1H
M.B X,30W"E@M3&EN97,Z(#$T-@H*4W1E<&5N.@H*4&QE87-E(&=I=F4@;64@
M8V]M96YT<R!O;B!M>2!A='1E;7!T('1O(&5X=&5N9"!P86-K86=E(&-O=7!L
M:6YG('=I=&@@;6EN;W(@"F%M;W5N="!O9B!W;W)K+B *"@H*"DD@86T@<')O
M<&]S:6YG(&9U<G1H97(@96YH86YC96UE;G1S('1O($))4D0@,C@N,PH*(" @
M(" @(" @(" @(" @("!"=69F97(@27-S=64@4F5S;VQU=&EO;B!$;V-U;65N
M=" @*$))4D0I"D))4D0@240C.B @(" @(" @*BHJ"DE34U5%(%1)5$Q%.B @
M(" @16YH86YC96UE;G0@5&\@5&AE(%!A8VMA9V4@36]D96P@*"YP86L@9FEL
M92D@4W!E8VEF:6-A=&EO;@I215%515-415(Z(" @(" @($,N($MU;6%R"D1!
M5$4@4U5"34E45$5$.B @3V-T(#$P+" Q.3DU"D1!5$4@04-#15!4140@0ED@
M24))4R!/4$5.($9/4E5-.B @4&5N9&EN9PH**BHJ*BHJ*BHJ*BHJ*BHJ*BHJ
M*BHJ*BHJ*BHJ*BHJ*BHJ*BHJ*BHJ*BHJ*BHJ*BHJ*BHJ*BHJ*BHJ*BHJ*BHJ
M*BHJ*BHJ*BHJ*BHJ*BHJ"BHJ*BHJ*BHJ*BHJ*BHJ*BHJ*BHJ*BHJ*BHJ*BHJ
M*BHJ*BHJ*BHJ*BHJ*BHJ*BHJ*BHJ*BHJ*BHJ*BHJ*BHJ*BHJ*BHJ*BHJ*BHJ
M*BHJ*@I35$%414U%3E0@3T8@5$A%($E34U5%.B!4:&4@96YH86YC960@<&%C
M:V%G92!M;V1E;" H0DE21" R."XS*2!P;&%C97,@<V]M92!U;FYE8V5S<V%R
M>2!R97-T<FEC=&EO;B!O;B!C;W5P;&5D('-E8W1I;VYS+B!4:&5S92!I;F-L
M=61E('1H92!R97%U:7)E;65N="!O9B!C;W5P;&EN9R!O;FQY(&9O<B!A9&IA
M8V5N="!S96-T:6]N<R!A;F0@=&AE(&%D9&ET:6]N86P@8G5R9&5N(&]F(&AA
M=FEN9R!T;R!H879E('1H92!S86UE(&YU;6)E<B!O9B!S96-T:6]N<RX@36EN
M;W(@<F5V:7-I;VYS('!R;W!O<V5D(&AE<F4@=VEL;"!R96UO=F4@=&AE<V4@
M<F5S=')I8W1I;VYS(&%N9"!M86ME('1H92!"25)$(&UO<F4@=6YI=F5R<V%L
M;'D@87!P;&EC86)L92!D:69F97)E;G0@='EP97,@;V8@<&%C:V%G97,N"@HJ
M*BHJ*BHJ*BHJ*BHJ*BHJ*BHJ*BHJ*BHJ*BHJ*BHJ*BHJ*BHJ*BHJ*BHJ*BHJ
M*BHJ*BHJ*BHJ*BHJ*BHJ*BHJ*BHJ*BHJ*BHJ*BHJ*BH*4U1!5$5-14Y4($]&
M(%1(12!215-/3%9%1"!34$5#249)0T%424].4SH@($9O;&QO=VEN9R!A<F4@
M=&AE('-P96-I9FEC(&-H86YG97,*=&\@=&AE('-P96-I9FEC871I;VXN"C$N
M(%1H92!K97EW;W)D(%M.=6UB97(@;V8@4V5C=&EO;G-=(&ES(&YO="!R97%U
M:7)E9"!S:6YC92!V87)I86)L92!N=6UB97(@;V8@"B @('-E8W1I;VYS(&9O
M<B!E86-H('!I;B!I<R!A;&QO=V5D"@H*,BX@5&AE(&-U<G)E;G0@6U!I;B!.
M=6UB97)S72!K97EW;W)D(&1E<V-R:7!T:6]N(&ES(')E<&QA8V5D(&)Y('1H
M92!F;VQL;W=I;F<Z"GP]/3T]/3T]/3T]/3T]/3T]/3T]/3T]/3T]/3T]/3T]
M/3T]/3T]/3T]/3T]/3T]/3T]/3T]/3T]/3T]/3T]/3T]/3T]/3T]/3T]/3T]
M/0I\(" @($ME>7=O<F0Z(%M0:6X@3G5M8F5R<UT*?" @(%)E<75I<F5D.B!9
M97,*?$1E<V-R:7!T:6]N.B!496QL<R!T:&4@<&%R<V5R('1H92!S970@;V8@
M;F%M97,@=&AA="!A<F4@=7-E9"!F;W(@=&AE('!A8VMA9V4*?" @(" @(" @
M(" @("!P:6YS(&%N9"!A;'-O(&1E9FEN97,@<&EN(&]R9&5R:6YG+B @16%C
M:"!P:6X@;G5M8F5R('-H;W5L9" *?" @(" @(" @(" @("!S=&%R="!A<R!T
M:&4@9FER<W0@8VAA<F%C=&5R(&EN(&$@;F5W(&QI;F4N"GP*?"!3=6(M4&%R
M86US.B!,96XL($PL(%(L($,L($UA=')I> I\57-A9V4@4G5L97,Z($9O;&QO
M=VEN9R!T:&4@6U!I;B!.=6UB97)S72!K97EW;W)D+"!T:&4@;F%M97,@;V8@
M=&AE('!I;G,@87)E"GP@(" @(" @(" @(" @;&ES=&5D+B @5&AE<F4@;75S
M="!B92!A<R!M86YY(&YA;65S(&QI<W1E9"!A<R!T:&5R92!A<F4@<&EN<PI\
M(" @(" @(" @(" @("AA<R!G:79E;B!B>2!T:&4@<')E8V5D:6YG(%M.=6UB
M97(@;V8@4&EN<UT@:V5Y=V]R9"DN("!0:6X@;F%M97,*?" @(" @(" @(" @
M("!C86X@;F]T(&5X8V5E9" U(&-H87)A8W1E<G,@:6X@;&5N9W1H+B @5&AE
M(&9I<G-T('!I;B!N86UE"GP@(" @(" @(" @(" @9VEV96X@:7,@=&AE(")L
M;W=E<W0B('!I;BP@86YD('1H92!L87-T('!I;B!G:79E;B!I<R!T:&4*?" @
M(" @(" @(" @(" B:&EG:&5S="XB( I\(" @(" @(" @(" @( I\(" @(" @
M(" @(" @(%-U8G!A<F%M971E<G,Z"GP@(" @(" @(" @(" @5&AE('-U8G!A
M<F%M971E<G,@<W!E8VEF>2!T:&4@;&5N9W1H+"!I;F1U8W1A;F-E+"!C87!A
M8VET86YC90I\(" @(" @(" @(" @(&%N9"!R97-I<W1A;F-E(&]F(&5A8V@@
M<V5C=&EO;B!O9B!E86-H('-T=6(@;VX@82!P86-K86=E+B @268*?" @(" @
M(" @(" @("!A('!A<G1I8W5L87(@<V5C=&EO;B!E>&AI8FET<R!C;W5P;&EN
M9R!T;R!A;B!A9&IA8V5N=" H<V%M90I\(" @(" @(" @(" @(&YU;6)E<F5D
M*2!S96-T:6]N(&]F(&$@9&EF9F5R96YT('!A8VMA9V4@<W1U8B!T:&5N('1H
M92!-871R:7@*?" @(" @(" @(" @("!S=6)P87)A;65T97(@:7,@=7-E9"X@
M(%1H92!S=6)P87)A;65T97)S(&%R92!D969I;F5D(&%S( I\(" @(" @(" @
M(" @(&9O;&QO=W,Z"GP@(" @(" @(" @(" @3&5N(" @("!4:&4@;&5N9W1H
M(&]F(&$@<&%C:V%G92!S='5B('-E8W1I;VXN("!,96YG=&AS(&%R92!G:79E
M;@I\(" @(" @(" @(" @(" @(" @(" @:6X@=&5R;7,@;V8@87)B:71R87)Y
M("=U;FET<R<N"GP@(" @(" @(" @(" @3" @(" @("!4:&4@:6YD=6-T86YC
M92!O9B!A('!A8VMA9V4@<W1U8B!S96-T:6]N+"!I;B!T97)M<R!O9@I\(" @
M(" @(" @(" @(" @(" @(" @)VEN9'5C=&%N8V4O=6YI="!L96YG=&@G+B @
M1F]R(&5X86UP;&4L(&EF('1H92!T;W1A; I\(" @(" @(" @(" @(" @(" @
M(" @:6YD=6-T86YC92!O9B!A('!A8VMA9V4@<W1U8B!S96-T:6]N(&ES(#,N
M,&Y((&%N9"!T:&4*?" @(" @(" @(" @(" @(" @(" @(&QE;F=T:"!O9B!T
M:&ES('-E8W1I;VX@:7,@,B G=6YI=',G+"!T:&4@:6YD=6-T86YC92 *?" @
M(" @(" @(" @(" @(" @(" @('=O=6QD(&)E(&QI<W1E9"!A<R!,(#T@,2XU
M;D@@("AI+F4N(#,N," O(#(I+B *?" @(" @(" @(" @("!#(" @(" @(%1H
M92!C87!A8VET86YC92!O9B!A('!A8VMA9V4@<W1U8B!S96-T:6]N+"!I;B!T
M97)M<R!O9@I\(" @(" @(" @(" @(" @(" @(" @8V%P86-I=&%N8V4@<&5R
M('5N:70@;&5N9W1H+@I\(" @(" @(" @(" @(%(@(" @(" @5&AE($1#("AO
M:&UI8RD@<F5S:7-T86YC92!O9B!A('!A8VMA9V4@<W1U8B!S96-T:6]N+"!I
M;@I\(" @(" @(" @(" @(" @(" @(" @=&5R;7,@;V8@;VAM<R!P97(@=6YI
M="!L96YG=&@N"GP@(" @(" @(" @(" @36%T<FEX("!5<V4@;V8@=&AI<R!S
M=6)P87)A;65T97(@;65A;G,@=&AA="!T:&ES('!A8VMA9V4@<W1U8@I\(" @
M(" @(" @(" @(" @(" @(" @<V5C=&EO;G,@96QE8W1R:6-A;"!P87)A;65T
M97)S(&%R92!P<F5S96YT960@87,@<&%R="!O9@I\(" @(" @(" @(" @(" @
M(" @(" @82!C;W5P;&EN9R!M871R:7@N("!4:&ES('-U8G!A<F%M971E<B!D
M969I;F5S('1H92 *?" @(" @(" @(" @(" @(" @(" @(&YA;64@;V8@=&AE
M(&UA=')I>"X@1F]R(&5X86UP;&4@36%T<FEX/3-,:6Y3=')I<"!D969I;F5S
M( I\(" @(" @(" @(" @(" @(" @(" @82!C;W5P;&5D('-E8W1I;VXL('!R
M;V)A8FQY(&-O;G1A:6YI;F<@,R!S=')I<"!L:6YE<RX@(" @"GP@(" @(" @
M(" @(" @(" @(" @("!4:&4@9&%T82!F;W(@=&AE(&UA=')I>"!I<R!I;F-L
M=61E9" *?" @(" @(" @(" @(" @(" @(" @(&)E='=E96X@=&AE(%M-;V1E
M;"!$871A72];16YD($UO9&5L($1A=&%=(&ME>7=O<F0@<&%I<G,*?" @(" @
M(" @(" @(" @(" @(" @(&%S(&1E<V-R:6)E9"!B96QO=RX@( H*?" @(" @
M(" @(" @("!->%!I;D]R9&5R($EF('1H92!K97D@=V]R9"!-871R:7@@:7,@
M=7-E9"!I="!S:&]U;&0@8F4@9F]L;&]W960*?" @(" @(" @(" @(" @(" @
M(" @(" @(&)Y($UX4&EN3W)D97(@=VAI8V@@9&5S8W)I8F5S('1H92!2;W<@
M;W)D97)I;F<*?" @(" @(" @(" @(" @(" @(" @(" @(&]F('1H92!M871R
M:7@@9VEV96X@:6X@<&%R96YT:&5S:7,N"GP@(" @(" @(" @(" @(" @(" @
M(" @("!&;W(@(&5X86UP;&4@"GP@(" @(" @(" @(" @(" @(" @(" @("!-
M871R:7@],TQI;E-T<FEP($UX4&EN3W)D97(]*$$Q($$R($$S*0I\(" @(" @
M(" @(" @(" @(" @(" @(" @<W!E8VEF:65S(&$@,W@S(&UA=')I>"!N86UE
M9" S3&EN4W1R:7 @=VAO<V4@<F]W"GP@(" @(" @(" @(" @(" @(" @(" @
M("!O<F1E<FEN9R!C;W)R97-P;VYD<R!T;R!2;W<@,2 ](%!I;B!!,2P@"GP@
M(" @(" @(" @(" @(" @(" @(" @("!2;W<@,B ](%!I;B!!,B!A;F0@4F]W
M(#,@/2!0:6X@03,*? I\(" @(" @(" @(" @(%-P96-I9GEI;F<@82!L96YG
M=&@@;W(@3"]2+T,@=F%L=64@;V8@>F5R;R!I<R!A;&QO=V5D+B @268*?" @
M(" @(" @(" @("!,96X@/2 P(&ES('-P96-I9FEE9"P@=&AE;B!T:&4@3"]2
M+T,@=F%L=65S(&%R92!T:&4@=&]T86P*?" @(" @(" @(" @("!F;W(@=&AA
M="!S96-T:6]N+B @268@82!N;VXM>F5R;R!L96YG=&@@:7,@<W!E8VEF:65D
M+"!T:&5N"GP@(" @(" @(" @(" @=&AE('1O=&%L($PO4B]#(&9O<B!A('-E
M8W1I;VX@:7,@8V%L8W5L871E9"!B>2!M=6QT:7!L>6EN9R *?" @(" @(" @
M(" @("!T:&4@=F%L=64@;V8@=&AE($QE;B!S=6)P87)A;65T97(@8GD@=&AE
M('9A;'5E(&]F('1H92!,+ I\(" @(" @(" @(" @(%(@;W(@0R!S=6)P87)A
M;65T97(N"GP*?" @(" @(" @(" @("!5<VEN9R!4:&4@4W5B<&%R86UE=&5R
M<R!T;R!$97-C<FEB92!086-K86=E(%-T=6(@4V5C=&EO;G,Z"GP@(" @(" @
M(" @(" @16%C:"!S96-T:6]N(&1E<V-R:7!T:6]N(&UU<W0@8F5G:6X@=VET
M:"!T:&4@3&5N('-U8G!A<F%M971E<B!A;F0*?" @(" @(" @(" @("!E;F1S
M('=I=&@@=&AE('-L87-H("@O*2!C:&%R86-T97(N("!4:&4@=F%L=64@;V8@
M82!S=6(M"GP@(" @(" @(" @(" @<&%R86UE=&5R(&%N9"!T:&4@<W5B<&%R
M86UE=&5R(&ET<V5L9B!A<F4@<V5P87)A=&5D(&)Y(&%N(&5Q=6%L<PI\(" @
M(" @(" @(" @('-I9VX@*#TI.R!W:&ET97-P86-E(&%R;W5N9"!T:&4@97%U
M86QS('-I9VX@:7,@;W!T:6]N86PN("!!;&P@"GP@(" @(" @(" @(" @<&%C
M:V%G92!S='5B(&1E<V-R:7!T:6]N<R!M=7-T(&-O;G1A:6X@=&AE('-A;64@
M;G5M8F5R(&]F( I\(" @(" @(" @(" @('-E8W1I;VYS(&AO=V5V97(L(&$@
M<&%R=&EC=6QA<B!S96-T:6]N(&1E<V-R:7!T:6]N(&-A;B!C;VYT86EN( I\
M(" @(" @(" @(" @(&YO(&1A=&$@*&DN92X@=&AE(&1E<V-R:7!T:6]N(&ES
M(&=I=F5N(&%S("=,96X@/2 P("\G+B @4V5E('1H92 *?" @(" @(" @(" @
M("!E>&%M<&QE(&)E;&]W*2X@( I\"GP@(" @(" @(" @(" @3&5G86P@4W5B
M<&%R86UE=&5R($-O;6)I;F%T:6]N<SH*?" @(" @(" @(" @("!!*2!!('-I
M;F=L92!,96X@/2 P('-U8G!A<F%M971E<BP@9F]L;&]W960@8GD@82!S;&%S
M:"X*?" @(" @(" @(" @("!4:&4@:7,@=7-E9"!T;R!D97-C<FEB92!A('-E
M8W1I;VX@=VET:"!N;R!D871A+@I\"GP@(" @(" @(" @(" @0BD@($QE;B!A
M;F0@='=O($UA=')I>"!S=6)P87)A;65T97)S+"!F;VQL;W=E9"!B>2!A"GP@
M(" @(" @(" @(" @8F%C:W-L87-H+B!4:&4@3&5N('-U8G!A<F%M971E<B!S
M<&5C:69I97,@=&AE(&QE;F=T:"!O9B!T:&%T( I\(" @(" @(" @(" @('-E
M8W1I;VX@=VAI;&4@=&AE($UA=')I>"!S=6)P87)A;65T97(@:6YD:6-A=&5S
M('1H870@=&AI<R *?" @(" @(" @(" @("!S96-T:6]N(&]F('1H:7,@<&%C
M:V%G92!S='5B(&ES(&5L96-T<FEC86QL>2!C;W5P;&5D('1O('1H92 *?" @
M(" @(" @(" @("!C;W)R97-P;VYD:6YG("AS86UE(&YU;6)E<F5D*2!S96-T
M:6]N(&]F(&%N(&%D:F%C96YT('!A8VMA9V4@"GP@(" @(" @(" @(" @<W1U
M8B H;W(@<W1U8G,I(&%N9"!T:&4@8V]U<&QI;F<@=&5R;7,@87)E(&QI<W1E
M9"!I;B!A(&UA=')I> I\(" @(" @(" @(" @(&9O<FUA="X@(%1H92!M871R
M:7@@9&5S8W)I<'1I;VX@;75S="!I;F-L=61E(&)O=&@@=&AE("=S96QF)R *
M?" @(" @(" @(" @("!I;F1U8W1A;F-E+V-A<&%C:71A;F-E+W)E<VES=&%N
M8V4@*&%S(')E<75I<F5D*2!O9B!A('-E8W1I;VX@"GP@(" @(" @(" @(" @
M87,@=V5L;"!A<R!T:&4@;75T=6%L(&-O=7!L:6YG('1E<FUS+B @268@;VYE
M('-E8W1I;VX@:7,*?" @(" @(" @(" @("!D97-C<FEB960@=7-I;F<@=&AE
M('1H92!-871R:7@@<W5B<&%R86UE=&5R('1H96X@=&AE( I\(" @(" @(" @
M(" @(&-O<G)E<W!O;F1I;F<@*'-A;64@;G5M8F5R960I('-E8W1I;VYS(&]N
M($%,3"!O=&AE<B!P86-K86=E( I\(" @(" @(" @(" @('-T=6)S(&UU<W0@
M=7-E('1H92!-871R:7@@<W5B<&%R86UE=&5R+B *? I\(" @(" @(" @(" @
M($,I("!,96XL(&%N9"!O;F4@;W(@;6]R92!O9B!T:&4@3"P@4B!A;F0@0R!S
M=6)P87)A;65T97)S+B @268*?" @(" @(" @(" @("!T:&4@3&5N('-U8G!A
M<F%M971E<B!I<R!G:79E;B!A<R!Z97)O+"!T:&5N('1H92!,+U(O0R!S=6(M
M"GP@(" @(" @(" @(" @<&%R86UE=&5R<R!R97!R97-E;G0@;'5M<&5D(&5L
M96UE;G1S+B @268@=&AE('1H92!,96X@<W5B+0I\(" @(" @(" @(" @('!A
M<F%M971E<B!I<R!N;VXM>F5R;RP@=&AE;B!T:&4@3"]2+T,@<W5B<&%R86UE
M=&5R<R!R97!R97-E;G0*?" @(" @(" @(" @("!D:7-T<FEB=71E9"!E;&5M
M96YT<RX*? I\"GP@(" @(" @(" @(" @26X@=&AE(&5X86UP;&4@8F5L;W<@
M=&AE(&9I<G-T('-E8W1I;VX@:7,@82!L=6UP960@:6YD=6-T;W(L"GP@(" @
M(" @(" @(" @=&AE('-E8V]N9"!S96-T:6]N(&ES(&1E<V-R:6)E9"!U<VEN
M9R!A(#,M;&EN92!M871R:7@L(&%N9" *?" @(" @(" @(" @("!T:&4@=&AI
M<F0*?" @(" @(" @(" @("!S96-T:6]N(&ES(&UO9&5L960@=7-I;F<@9&ES
M=')I8G5T960@96QE;65N=',N("!0:6X@03,@<VAO=W,*?" @(" @(" @(" @
M("!A;B!E>&%M<&QE(&]F('-E8W1I;VYS('=I=&@@;F\@9&%T82X@(%!I;B!!
M,R!A;'-O('-H;W=S(&$@"GP@(" @(" @(" @(" @,FQI;F4@;6%T<FEX('-E
M8W1I;VX@8V]U<&QE9"!T;R!!-2$@4&EN<R!!-"!A;F0@034@:6QL=7-T<F%T
M90I\(" @(" @(" @(" @(&AO=R!A('-E8W1I;VX@9&5S8W)I<'1I;VX@8V%N
M(&)E(&)R;VME;B!A8W)O<W,@;75L=&EP;&4@;&EN97,*?" @(" @(" @(" @
M("!A;F0@:&]W(&5A8V@@<V5C=&EO;B!D97-C<FEP=&EO;B!I<R!D96QI;6ET
M960@8GD@=&AE('-L87-H+@I\+2TM+2TM+2TM+2TM+2TM+2TM+2TM+2TM+2TM
M+2TM+2TM+2TM+2TM+2TM+2TM+2TM+2TM+2TM+2TM+2TM+2TM+2TM+2TM+2TM
M+2TM+2T*6U!I;B!.=6UB97)="D$Q(" @3&5N(#T@,"!,/3$N,FX@+R!,96X@
M/2 Q+C,@36%T<FEX/3-L:6YE($UX4&EN3W)D97(]*$$Q($$R($$S*2 O( H@
M(" @($QE;CTP+C0W($P]."XS-6X@0STS+C,T<"!2/3 N,#$@+PI!,B @($QE
M;B ](# @3#TQ+C1N("\@3&5N(#T@,2XR($UA=')I>#TS;&EN92!->%!I;D]R
M9&5R/2A!,2!!,B!!,RDO( H@(" @($QE;CTP+C0W($P]-BXR,6X@0STS+C,T
M<"!2/3 N,#$@+PI!,R @($QE;B ](# @(" @(" @("\@3&5N(#T@,2XQ($UA
M=')I>#TS;&EN92!->%!I;D]R9&5R/2A!,2!!,B!!,RD@("\@"B @(" @3&5N
M(#T@," @36%T<FEX/3)L:6YE($UX4&EN3W)D97(]*$$S($$U*2 @(" @(" @
M(" @(" @(" @(" @(" @+PI!-" @($QE;B ](# @3#TQ+C)N("\@3&5N(#T@
M,2XP($P],FY(("\@3&5N/3 N-#<@3#TX+C,U;B *(" @("!#/3,N,S1P(%(]
M,"XP,2\*034@("!,96X@/2 P($P],2XR;B O(" *(" @("!,96X],2XR($UA
M=')I>#TR;&EN92!->%!I;D]R9&5R/2A!,R!!-2D@+R *(" @("!,96X],"XT
M-R!,/2 X+C,U;B!#/3,N,S1P(%(],"XP,2 O"GP*?" @("!.;W1E('1H870@
M=&AE(&%C='5A;"!L96YG=&@@9F]R(&5A8V@@<V5C=&EO;B!I<R!R97!O<G1E
M9"P@979E;B!F;W(*?" @("!T:&]S92!S96-T:6]N<R!T:&%T('5S92!T:&4@
836%T<FEX('-U8G!A<F%M971E<BX*? H*
 
end

From admin@cae9.caeconsult.com  Thu Oct 26 04:55:25 1995
Return-Path: <admin@cae9.caeconsult.com>
Received: from cls.net (freeside.cls.de) by vhdl.vhdl.org (4.1/SMI-4.1/BARRNet)
	id AA17707; Thu, 26 Oct 95 04:55:25 PDT
Received: by mail.cls.net (Smail3.1.28.1)
	  from cae9.caeconsult.com (194.64.174.12) with smtp
	  id <m0t8QnJ-0011iYC@cls.net>; Thu, 26 Oct 95 11:48 GMT
Received: by cae9.caeconsult.com (4.1/SMI-4.1)
	id AA28043; Thu, 26 Oct 95 12:49:00 +0100
Date: Thu, 26 Oct 95 12:49:00 +0100
From: admin@cae9.caeconsult.com (Administrator of cae consulting)
Message-Id: <9510261149.AA28043@cae9.caeconsult.com>
To: ibis@vhdl.org
Subject: subsribe


To: ibis@vhdl.org
Fr: Sven Rau



                                         26th October 1995

Dear Sirs,

* We would like you to send us the IBIS Model List of Intel. 

* Do we have to pay for it?

With best regards,


Sven Rau




+-----------------------------------------------------------+
| cae consulting Sven Rau GmbH        Tel. +49(0)7641-53025 |
| Blauenstr. 8,  D-79350 Sexau        Fax. +49(0)7641-53967 | 
| e-mail: admin@caeconsult.com                              | 
+-----------------------------------------------------------+


From celso@unicad.com  Thu Oct 26 07:04:45 1995
Return-Path: <celso@unicad.com>
Received: from unigate2 ([199.43.4.3]) by vhdl.vhdl.org (4.1/SMI-4.1/BARRNet)
	id AA18446; Thu, 26 Oct 95 07:04:45 PDT
Received: from unigate.unicad.com by unigate2 with smtp
	(Smail3.1.28.1 #7) id m0t8Si7-000LdBC; Thu, 26 Oct 95 09:51 EDT
Received: from [199.43.5.36] by unigate.unicad.com (AIX 3.2/UCB 5.64/4.03)
          id AA16811; Thu, 26 Oct 1995 09:58:20 -0400
From: Celso Faia <celso@unicad.com>
Received: by unihsa0.unicad.com (1.38.193.4) id AA03230; Thu, 26 Oct 1995 09:52:55 -0400
Message-Id: <9510261352.AA03230@unihsa0.unicad.com>
Subject: s2ibis compatability
To: ibis@vhdl.org
Date: Thu, 26 Oct 1995 09:52:55 -0500 (EDT)
X-Mailer: ELM [version 2.4 PL22]
Content-Type: text
Content-Length: 861       

Hello fellow IBISans,

My question involves the compatability of s2ibis with hpsice for Windows NT.

I downloaded various s2ibis zipped files from /pub/ibis/s2ibis directory and
found that only s2ibis_v1.0, which is for windows, was the only one that I could
pkunzip properly.  My Hspice version is that of Win 95.3.  Now how do I get
these two programs to work together properly?  Is there another version
of S2IBIS that is better to use in windows?  Ideally I would like S2IBIS
version 1.1 or 1.2. 

I did test the two programs together and found that s2ibis could not find
hpsice.  Now both my s2ibis and hspice are in my path so that's not the
problem.  I am trying to recompile s2ibis and making modifications but 
in the mean time if anyone has any advice on this  matter I would greatly 
appreciate it.

Thank You,

Celso Faia
email : Celso@unicad.com  

From bob@icx.com  Thu Oct 26 09:57:50 1995
Return-Path: <bob@icx.com>
Received: from icx.com (icx.rain.com) by vhdl.vhdl.org (4.1/SMI-4.1/BARRNet)
	id AA19326; Thu, 26 Oct 95 09:57:50 PDT
Received: by icx.com (/\==/\ Smail3.1.28.1 #28.14)
	id <m0t8VTG-000FVWC@icx.com>; Thu, 26 Oct 95 09:48 PDT
Received: by icx.com (/\==/\ Smail3.1.28.1 #28.14)
	id <m0t8VVq-000GjSC@icx.com>; Thu, 26 Oct 95 09:50 PDT
Message-Id: <m0t8VVq-000GjSC@icx.com>
Date: Thu, 26 Oct 95 09:50 PDT
From: bob@icx.com ( Bob Ross)
To: celso@unicad.com, ibis@vhdl.org, kellee@hyperlynx.com
Subject: Re:  s2ibis compatability (fwd)
Cc: awglaser@eos.ncsu.edu, mbs@ncsu.edu, slipa@eos.ncsu.edu

Kellee:

Can you help generate PC compatible Windows versions of Versions 1.2 and 2.091?
Or can anyone else provide assistance to these problems?

Any further progress with respect to your compilation problems of the
October 16 Memo?  I think the best contact is Alan Glaser (919) 515-3947.

Attached is some correspondence related to this issue.

Bob Ross
Interconnectix, Inc.

> Hello fellow IBISans,

> My question involves the compatability of s2ibis with hpsice for Windows NT.

> I downloaded various s2ibis zipped files from /pub/ibis/s2ibis directory and
> found that only s2ibis_v1.0, which is for windows, was the only one that I could
> pkunzip properly.  My Hspice version is that of Win 95.3.  Now how do I get
> these two programs to work together properly?  Is there another version
> of S2IBIS that is better to use in windows?  Ideally I would like S2IBIS
> version 1.1 or 1.2. 

> I did test the two programs together and found that s2ibis could not find
> hpsice.  Now both my s2ibis and hspice are in my path so that's not the
> problem.  I am trying to recompile s2ibis and making modifications but 
> in the mean time if anyone has any advice on this  matter I would greatly 
> appreciate it.

> Thank You,

> Celso Faia
> email : Celso@unicad.com  


From: mbs@eos.ncsu.edu
To: ibis@vhdl.org
Subject: S2IBIS'95 .... start
Date: Tue, 12 Sep 95 22:27:03 EDT

Actually version 2.

S2IBIS2 has been released as beta code.
S2IBIS2 supports the automatic generation of IBIS model
given a SPICE model.  All features of IBIS veriosn 2.1 are supported except
for the package parameters which must be acquired by some other means.

The code, documentation and compiled binaries for RS6000, DEC 3000/5000, HPUX,
and SUN are available in pub/ibis/s2ibis/s2ibis_v2.0/s2ibis2.tar.Z

The code and documentation only
are available in pub/ibis/s2ibis/s2ibis_v2.0/s2ibis2.zip

We do need a Microsoft windows version (3.x please) ...  any volunteers?
(It compiles using gnu tools so if these are used there should be no
problems.)  Send contribution to me <mbs@ncsu.edu> and I will put
them on vhdl.org

The code has no known bugs.  We will
collect bug reports addressed to awglaser@eos.ncsu.edu.
We hope to be able to correct bugs pending future support.

Thanks go to CADENCE for their generous support of the S2IBIS2 development.

Thanks to Bob Ross for his help in establishing voltage sweep ranges
and ironing out the ECL supply ambiguity in the IBIS2.1 spec.


Michael Steer
IBIS LIBRARIAN

on behalf of the S2IBIS development team

Alan Glaser (a supper effort, he has a month of sleep to catch up on)
Steve Lipa
Michael Steer
Paul Franzon

North Carolina State University


Date: Mon, 16 Oct 1995 10:42:30 -0700
To: ibis@vhdl.org
From: Kellee Crisafulli <kellee@hyperlynx.com>
Subject: Spice to IBIS for windows

I am trying to compile the spice to IBIS converter
to run under windows/3.1, 95, NT and am having trouble
getting some of the lex functions to compile.

If I can get it to compile I will send it to Michael Steer.

Who is the best contact at N.C. about compile problems?

Have a great day...Kellee Crisafulli, HyperLynx Inc.







From fvance@freedom.firepower.com  Fri Oct 27 14:25:58 1995
Return-Path: <fvance@freedom.firepower.com>
Received: from firepower.com (freespeech.firepower.com) by vhdl.vhdl.org (4.1/SMI-4.1/BARRNet)
	id AA01870; Fri, 27 Oct 95 14:25:58 PDT
Received: from freedom.firepower.com (freedom.firepower.com [198.4.104.3]) by firepower.com (8.7.1/8.7.1) with ESMTP id OAA03176 for <ibis@vhdl.org>; Fri, 27 Oct 1995 14:17:47 -0700 (PDT)
Received: from protocol.FirePower.COM (protocol [198.4.104.87]) by freedom.firepower.com (8.7.1/8.7.1) with SMTP id OAA10629 for <ibis@vhdl.org>; Fri, 27 Oct 1995 14:18:31 -0700 (PDT)
From: Fred Vance <fvance@firepower.com>
Message-Id: <199510272118.OAA10629@freedom.firepower.com>
Received: by protocol.FirePower.COM (NX5.67d/NX3.0X)
	id AA01277; Fri, 27 Oct 95 14:18:34 -0700
Date: Fri, 27 Oct 95 14:18:34 -0700
Received: by NeXT.Mailer (1.99.1)
Received: by NeXT Mailer (1.99.1)
To: ibis@vhdl.org
Subject: IBIS to Proprietary Simulator Model Conversion Tools

EDA Companies,

IBIS to proprietary model, conversion tools don't make sense to me. Why not  
have your simulators use IBIS models directly? If your simulation tool does use  
IBIS models directly (without a separate conversion utility), I would like to  
know who you are.

Some of you even plan to charge outrageous (to me) amounts of money for such  
conversion tools.

IBIS is the standard for exchange of information on I/O Buffers. You will need  
to have IBIS capability to be a viable tool vendor in the future (at least for  
signal integrity and timing analysis work). Why put an additional hurdle in the  
way of your customers?

A proprietary model to IBIS conversion tool would make more sense to me than  
converting in the other direction. Such a tool might be worth buying. The most  
important model to IBIS conversion tool, from my perspective, is s2ibis, and I  
believe it is free.

If you are one of the companies that make a variant of SPICE simulator, you  
should be especially eager to provide IBIS compatibility. The use of IBIS  
models will speed up your simulator and narrow the speed gap between you and  
non-SPICE type simulators.

Am I missing something here? I'm aware that there are analog simulations to  
which IBIS models may never be successfully applied, but for digital signal  
integrity work, IBIS is the way of the future.

Fred Vance
FirePower Systems, Inc.



From uunet!qdt.com!jonp@uunet.uu.net  Fri Oct 27 18:22:37 1995
Return-Path: <uunet!qdt.com!jonp@uunet.uu.net>
Received: from relay5.UU.NET by vhdl.vhdl.org (4.1/SMI-4.1/BARRNet)
	id AA02811; Fri, 27 Oct 95 18:22:37 PDT
Received: from uucp2.UU.NET by relay5.UU.NET with SMTP 
	id QQznij11159; Fri, 27 Oct 1995 21:15:04 -0400 (EDT)
Received: from qdt.UUCP by uucp2.UU.NET with UUCP/RMAIL
        ; Fri, 27 Oct 1995 21:15:04 -0400
Received: from hal.qdt.com by qdt.com (4.1/SMI-4.1)
	id AA01492; Fri, 27 Oct 95 17:38:08 PDT
Received: from qdt.com by hal.qdt.com (4.1/SMI-4.1)
	id AA07200; Fri, 27 Oct 95 17:38:08 PDT
Received: from uucp6.UU.NET by relay5.UU.NET with SMTP 
	id QQznig05901; Fri, 27 Oct 1995 20:35:05 -0400 (EDT)
Received: from qdt.UUCP by uucp6.UU.NET with UUCP/RMAIL
        ; Fri, 27 Oct 1995 20:35:05 -0400
Received: from hal.qdt.com by qdt.com (4.1/SMI-4.1)
	id AA01442; Fri, 27 Oct 95 16:51:09 PDT
Received: from f14.qdt.com by hal.qdt.com (4.1/SMI-4.1)
	id AA06908; Fri, 27 Oct 95 16:51:09 PDT
Date: Fri, 27 Oct 95 16:51:09 PDT
From: uunet!qdt.com!jonp@uunet.uu.net (Jon Powell)
Message-Id: <9510272351.AA06908@hal.qdt.com>
Received: by f14.qdt.com (4.1/SMI-4.1)
	id AA16354; Fri, 27 Oct 95 16:51:07 PDT
To: uunet!uunet!firepower.com!fvance@uunet.uu.net
Cc: uunet!uunet!vhdl.org!ibis@uunet.uu.net
In-Reply-To: <199510272118.OAA10629@freedom.firepower.com> (uunet!firepower.com!fvance)
Subject: Re: IBIS to Proprietary Simulator Model Conversion Tools

Fred,

I can reply for QUAD DESIGN:

1) We supply an IBIS converter, at no extra cost, as a part of our tool. 

2) Historically, the IBIS standard did not support the same level of information
that an XTK model supports. That is, the XTK models could model certain objects that
IBIS could not model and so if we supported IBIS as our sole language we would either
be reducing our capability or making a "dialect" of IBIS, neither of which we wanted
to do. (we still want to be able to release advanced behavioral simulation constructs
that have not had time for IBIS approval).

3) IBIS is NOT a simulation language but a data exchange mechanism targetted at SI
problems. Translating it into a simulation language seems appropriate under many conditions.

4) IBIS does not contain certain timing information that is essential to the Quad Design methodology
for SI simulation. We insert this information during the translation process.

5) For simple devices, Quad Design models are much easier to write than IBIS models. We have a huge
user base trained in writting Quad Design models and they would kill us if we switched to IBIS.

6) IBIS is God and if a mere SI program touched it directly it would burst into flame.




From mbs@eos.ncsu.edu  Mon Oct 30 06:10:31 1995
Return-Path: <mbs@eos.ncsu.edu>
Received: from mbs.ece.ncsu.edu (c11058-335dan.ece.ncsu.edu) by vhdl.vhdl.org (4.1/SMI-4.1/BARRNet)
	id AA02097; Mon, 30 Oct 95 06:10:31 PST
Received: by mbs.ece.ncsu.edu (5.65/Eos/C-U-09Sep93)
	id AA04398; Mon, 30 Oct 1995 09:03:02 -0500
From: "Michael B Steer" <mbs@eos.ncsu.edu>
Message-Id: <9510300903.ZM4396@eos.ncsu.edu>
Date: Mon, 30 Oct 1995 09:03:01 -0500
In-Reply-To: Celso Faia <celso@unicad.com>
        "s2ibis compatability" (Oct 26,  9:52am)
References: <9510261352.AA03230@unihsa0.unicad.com>
X-Mailer: Z-Mail (3.2.1 15feb95)
To: ibis@vhdl.org, Celso Faia <celso@unicad.com>
Subject: Re: s2ibis compatability
Mime-Version: 1.0
Content-Type: text/plain; charset=us-ascii

Celso,

My team at NC State University wrote S2IBIS but only compiled it for Unix
workstations.  We were hoping that someone else would compile it for PCs.
The original versions of S2IBIS, v1.x, do have windows executables.  So far an
windows executable for the latest S2IBIS, v2.x, have not been posted.  Error
handling and flexibility of v2.x is much better than that of v1.x even for v1.1
IBIS files.  We really do need a windows version of v2.x compiled.  However, we
are a Unix-only house.  (We run Unix (Linux) on our PCs too.)

Michael Steer
NC State University


On Oct 26,  9:52am, Celso Faia wrote:
> Subject: s2ibis compatibility
> Hello fellow IBISans,
>
> My question involves the compatibility of s2ibis with hpsice for Windows NT.
>
> I down-loaded various s2ibis zipped files from /pub/ibis/s2ibis directory and
> found that only s2ibis_v1.0, which is for windows, was the only one that I
could
> pkunzip properly.  My Hspice version is that of Win 95.3.  Now how do I get
> these two programs to work together properly?  Is there another version
> of S2IBIS that is better to use in windows?  Ideally I would like S2IBIS
> version 1.1 or 1.2.

No you really want S2IBIS v2.x

>
> I did test the two programs together and found that s2ibis could not find
> hpsice.  Now both my s2ibis and hspice are in my path so that's not the
> problem.  I am trying to recompile s2ibis and making modifications but
> in the mean time if anyone has any advice on this  matter I would greatly
> appreciate it.
>
> Thank You,
>
> Celso Faia
> email : Celso@unicad.com
>-- End of excerpt from Celso Faia



From fvance@freedom.firepower.com  Mon Oct 30 10:05:23 1995
Return-Path: <fvance@freedom.firepower.com>
Received: from firepower.com (freespeech.firepower.com) by vhdl.vhdl.org (4.1/SMI-4.1/BARRNet)
	id AA03624; Mon, 30 Oct 95 10:05:23 PST
Received: from freedom.firepower.com (freedom.firepower.com [198.4.104.3]) by firepower.com (8.7.1/8.7.1) with ESMTP id JAA06216; Mon, 30 Oct 1995 09:57:00 -0800 (PST)
Received: from protocol.FirePower.COM (protocol [198.4.104.87]) by freedom.firepower.com (8.7.1/8.7.1) with SMTP id JAA01633; Mon, 30 Oct 1995 09:57:46 -0800 (PST)
From: Fred Vance <fvance@firepower.com>
Message-Id: <199510301757.JAA01633@freedom.firepower.com>
Received: by protocol.FirePower.COM (NX5.67d/NX3.0X)
	id AA02004; Mon, 30 Oct 95 09:57:52 -0800
Date: Mon, 30 Oct 95 09:57:52 -0800
Received: by NeXT.Mailer (1.99.1)
Received: by NeXT Mailer (1.99.1)
To: uunet!qdt.com!jonp@uunet.uu.net (Jon Powell)
Subject: Re: IBIS to Proprietary Simulator Model Conversion Tools
Cc: ibis@vhdl.org

Jon,

In reply to items (1) to (6) below:

(1) I applaude your prowess in supporting IBIS.

(2) Historically, you have also introduced models of increasing complexity as  
the demand for them arose.

(3) Thank goodness. If IBIS were a simulation language, we'd never get any  
consensus on it.

(4) So? Associate the timing information with the IBIS model during  
translation.

(5) Using IBIS models shouldn't preclude the use of simpler (or more complex)  
models.

(6) Absolutely. Just allow your SI program to commune with the IBIS scriptures  
for a divine revelation.

Fred


Begin forwarded message:

Date: Fri, 27 Oct 95 16:51:09 PDT
From: uunet!qdt.com!jonp@uunet.uu.net (Jon Powell)
To: uunet!uunet!firepower.com!fvance@uunet.uu.net
Cc: uunet!uunet!vhdl.org!ibis@uunet.uu.net
In-Reply-To: <199510272118.OAA10629@freedom.firepower.com>  
(uunet!firepower.com!fvance)
Subject: Re: IBIS to Proprietary Simulator Model Conversion Tools

Fred,

I can reply for QUAD DESIGN:

1) We supply an IBIS converter, at no extra cost, as a part of our tool. 


2) Historically, the IBIS standard did not support the same level of  
information
that an XTK model supports. That is, the XTK models could model certain objects  
that
IBIS could not model and so if we supported IBIS as our sole language we would  
either
be reducing our capability or making a "dialect" of IBIS, neither of which we  
wanted
to do. (we still want to be able to release advanced behavioral simulation  
constructs
that have not had time for IBIS approval).

3) IBIS is NOT a simulation language but a data exchange mechanism targetted at  
SI
problems. Translating it into a simulation language seems appropriate under  
many conditions.

4) IBIS does not contain certain timing information that is essential to the  
Quad Design methodology
for SI simulation. We insert this information during the translation process.

5) For simple devices, Quad Design models are much easier to write than IBIS  
models. We have a huge
user base trained in writting Quad Design models and they would kill us if we  
switched to IBIS.

6) IBIS is God and if a mere SI program touched it directly it would burst into  
flame.





From EGJJ77A@mail.prodigy.com  Mon Oct 30 12:12:12 1995
Return-Path: <EGJJ77A@mail.prodigy.com>
Received: from pimaia2w.prodigy.com by vhdl.vhdl.org (4.1/SMI-4.1/BARRNet)
	id AA04538; Mon, 30 Oct 95 12:12:12 PST
Received: from mail.prodigy.com ([199.4.137.13]) by pimaia2w.prodigy.com (8.6.10/8.6.9) with SMTP id PAA45322; Mon, 30 Oct 1995 15:34:35 -0400
Date: Mon, 30 Oct 1995 14:33:50 EST
From: EGJJ77A@prodigy.com (MR RONALD J CHRISTOPHER)
X-Mailer: PRODIGY Services Company Internet mailer [PIM 3.2-342.56]
Message-Id: <013.03835727.EGJJ77A@prodigy.com>
To: ibis@vhdl.org, prusher@eia.org
Subject: CFI, EDAC, Sematech 10 year roadmap Presentation

-- [ From: Ron Christopher * EMC.Ver #2.10P ] --

The foils used for the presentation of the CFI, EDAC, Sematech 10 year
roadmap to the Industry Council which Patti Rusher mentioned in the
teleconference call are at:
cfi.org/public/Cfi/Development/Roadmap/EII/RM-Pitch.ps dated Oct 23,
1995.

The latest level of the roadmap is at the same directory /roadmap.ps
dated October 24, 1995.

Ron Christopher 


From esayre@nesa.com  Mon Oct 30 12:47:49 1995
Return-Path: <esayre@nesa.com>
Received: from wile.nesa.com ([204.240.29.34]) by vhdl.vhdl.org (4.1/SMI-4.1/BARRNet)
	id AA04766; Mon, 30 Oct 95 12:47:49 PST
Date: Mon, 30 Oct 1995 15:40:05 -0500
Message-Id: <199510302040.PAA22498@wile.nesa.com>
Received: from tweety.nesa.com(204.240.29.37) by wile.nesa.com via smap (V1.3)
	id sma022496; Mon Oct 30 15:40:02 1995
X-Sender: esayre@mail.nesa.com
X-Mailer: Windows Eudora Light Version 1.5.2
Mime-Version: 1.0
Content-Type: text/plain; charset="us-ascii"
To: huq@rockie.nsc.com (Syed Huq)
From: "Dr. Edward P. Sayre" <esayre@nesa.com>
Subject: Re: Face to Face 1996 
Cc: ibis@vhdl.org

It would be more convenient if an IBIS meeting or two were held on the East
Coast, preferably in the Boston area. Stuff is going on here as well.

ed sayre


From kellee@washington.nwlink.com  Mon Oct 30 13:11:25 1995
Return-Path: <kellee@washington.nwlink.com>
Received: from washington.nwlink.com (nwlink.com) by vhdl.vhdl.org (4.1/SMI-4.1/BARRNet)
	id AA04896; Mon, 30 Oct 95 13:11:25 PST
Received: (from kellee@localhost) by washington.nwlink.com (8.6.12/8.6.12) id MAA12805; Mon, 30 Oct 1995 12:56:56 -0800
Date: Mon, 30 Oct 1995 12:56:56 -0800
Message-Id: <199510302056.MAA12805@washington.nwlink.com>
X-Sender: kellee@hyperlynx.com
X-Mailer: Windows Eudora Pro Version 2.1.2
Mime-Version: 1.0
Content-Type: text/plain; charset="us-ascii"
To: ibis@vhdl.org
From: Kellee Crisafulli <kellee@hyperlynx.com>
Subject: Fred Vance's letter on EDA Companies supporting IBIS directly 

Hi Fred,

In reply to your question:
  IBIS to proprietary model, conversion tools don't make sense to me. Why not  
  have your simulators use IBIS models directly? If your simulation tool
does use  
  IBIS models directly (without a separate conversion utility), I would like
to  
  know who you are.

  HyperLynx Inc. supports IBIS files directly with all of our signal integrity
  simulation tools.

  If you would like more information let me know and I will pass your name to
  the marketing people.






Have a great day...Kellee Crisafulli, HyperLynx Inc.


From fvance@freedom.firepower.com  Mon Oct 30 13:47:08 1995
Return-Path: <fvance@freedom.firepower.com>
Received: from firepower.com (freespeech.firepower.com) by vhdl.vhdl.org (4.1/SMI-4.1/BARRNet)
	id AA05128; Mon, 30 Oct 95 13:47:08 PST
Received: from freedom.firepower.com (freedom.firepower.com [198.4.104.3]) by firepower.com (8.7.1/8.7.1) with ESMTP id NAA07117; Mon, 30 Oct 1995 13:38:40 -0800 (PST)
Received: from protocol.FirePower.COM (protocol [198.4.104.87]) by freedom.firepower.com (8.7.1/8.7.1) with SMTP id NAA04685; Mon, 30 Oct 1995 13:39:26 -0800 (PST)
From: Fred Vance <fvance@firepower.com>
Message-Id: <199510302139.NAA04685@freedom.firepower.com>
Received: by protocol.FirePower.COM (NX5.67d/NX3.0X)
	id AA02108; Mon, 30 Oct 95 13:39:33 -0800
Date: Mon, 30 Oct 95 13:39:33 -0800
Received: by NeXT.Mailer (1.99.1)
Received: by NeXT Mailer (1.99.1)
To: Kellee Crisafulli <kellee@hyperlynx.com>
Subject: EDA Companies supporting IBIS directly 
Cc: ibis@vhdl.org

Yes, please.

Fred Vance
Engineer

FirePower Systems, Inc.
190 Independence Drive
Menlo Park, CA 94025
(415) 462-3055

Begin forwarded message:

Date: Mon, 30 Oct 1995 12:56:56 -0800
X-Sender: kellee@hyperlynx.com
X-Mailer: Windows Eudora Pro Version 2.1.2
Mime-Version: 1.0
Content-Type: text/plain; charset="us-ascii"
To: ibis@vhdl.org
From: Kellee Crisafulli <kellee@hyperlynx.com>
Subject: Fred Vance's letter on EDA Companies supporting IBIS directly 


Hi Fred,

In reply to your question:
  IBIS to proprietary model, conversion tools don't make sense to me. Why not  

  have your simulators use IBIS models directly? If your simulation tool
does use  

  IBIS models directly (without a separate conversion utility), I would like
to  

  know who you are.

  HyperLynx Inc. supports IBIS files directly with all of our signal integrity
  simulation tools.

  If you would like more information let me know and I will pass your name to
  the marketing people.






Have a great day...Kellee Crisafulli, HyperLynx Inc.



From Will_Hobbs@ccm.jf.intel.com  Mon Oct 30 14:54:35 1995
Return-Path: <Will_Hobbs@ccm.jf.intel.com>
Received: from ormail.intel.com by vhdl.vhdl.org (4.1/SMI-4.1/BARRNet)
	id AA05517; Mon, 30 Oct 95 14:54:35 PST
Received: from relay.jf.intel.com by ormail.intel.com with smtp
	(Smail3.1.28.1 #7) id m0tA2w2-000UkFC; Mon, 30 Oct 95 14:44 PST
Received: from ccm.jf.intel.com by relay.jf.intel.com
	(Smail3.1.28.1 #2) id m0tA2w2-000twWC; Mon, 30 Oct 95 14:44 PST
Received: by ccm.jf.intel.com (ccmgate 3.2 #3) Mon, 30 Oct 95 14:44:06 PST
Date: Mon, 30 Oct 95 14:43:00 PST
From: Will Hobbs <Will_Hobbs@ccm.jf.intel.com>
Message-Id: <Mon, 30 Oct 95 14:44:02 PST_2@ccm.jf.intel.com>
To: esayre@nesa.com, huq@rockie.nsc.com
Cc: ibis@vhdl.org
Subject: Re[2]: Face to Face 1996


Text item: 

Ed,

I don't disagree with your sentiment.  Half of our face-t-face meetings have 
been held at DAC, which has been in Dallas, San Diego and San Francisco in the 
past 3 years.  The other half have been hosted by Intel, which is also on the 
western side of the Mississippi.  With NSC hosting the next one in Santa 
Clara, again the geocenter is in the west. I believe the next DAC is in Las 
Vegas, continuing the trend. Our meetings are usually linked with some event 
that already justifies the travel expenses of many IBIS participants, such as 
DAC.  If there is a suitable event and a sponsor on the east coast, I doubt 
that many would object to a change of scene.  However, I think it is too late 
to change it for the next two meetings. Suggestions?  

Regards,

Will Hobbs
Intel Corp.
Chair, IBIS Open Forum

 It would be more convenient if an IBIS meeting or two were held on the East 
Coast, preferably in the Boston area. Stuff is going on here as well.

ed sayre

Text item: External Message Header

The following mail header is for administrative use
and may be ignored unless there are problems.

***IF THERE ARE PROBLEMS SAVE THESE HEADERS***.

Cc: ibis@vhdl.org
Subject: Re: Face to Face 1996
From: "Dr. Edward P. Sayre" <esayre@nesa.com>
To: huq@rockie.nsc.com (Syed Huq)
Content-Type: text/plain; charset="us-ascii"
Mime-Version: 1.0
X-Mailer: Windows Eudora Light Version 1.5.2
X-Sender: esayre@mail.nesa.com
Received: from tweety.nesa.com(204.240.29.37) by wile.nesa.com via smap (V1.3)
     id sma022496; Mon Oct 30 15:40:02 1995
Message-Id: <199510302040.PAA22498@wile.nesa.com>
Date: Mon, 30 Oct 1995 15:40:05 -0500
Received: from wile.nesa.com ([204.240.29.34]) by vhdl.vhdl.org (4.1/SMI-4.1/BAR
RNet)
     id AA04766; Mon, 30 Oct 95 12:47:49 PST
Received: from vhdl.vhdl.org by aurora.intel.com (5.65/10.0i); Mon, 30 Oct 95 13
:38:14 -0800
Received: from aurora.intel.com by ichips.intel.com (5.64+/10.0i); Mon, 30 Oct 9
5 13:38:25 -0800
Received: from ichips.intel.com by relay.jf.intel.com with smtp
     (Smail3.1.28.1 #2) id m0tA1uV-000twVC; Mon, 30 Oct 95 13:38 PST