BIRD30 Comment

To Arpad, Malan, IBIS Committee:

I have been following the discussion regarding BIRD30 and have these
additional comments. Eventually, I will be concerned about some
syntax details, but at this time I am more concerned about the concepts
and capabilities.

The suggestion of providing selection of programmable buffers by some
attribute method is very nice and would support some practical applications.
However, at this time my position is to focus on the simpler selection
by name method because

(1) It captures the alternatives with the [Component] description for
     IBIS file default settings in one location rather than requiring
     inserting additional "Classes" information in [Model]s throughout
     the IBIS file.

(2) Selection by name is consistent with existing selection methods for
     [Component], [Model], and [Package Model]. Names for alternative
     models could be descriptive, although this is not required. For
     ASIC models, the names are reasonably descriptive.

(3) Simulators can extend any existing selection method most easily by
     named alternatives rather than by characteristics (even though there
     is some attractiveness to this approach). Setting up the IBIS file
     defaults or initial selections is one level. Ideally, simulators
     would have a corresponding mechanism to override the selection and
     support components configured differently in different locations.

(4) It does not involve standardizing the "Classes" list of attributes.
     It does not involve establishing a new set of rules, restrictions,
     and possibly more defaults.

Here are some possible areas where the [Model Selector] method could
be used:

(1) Configurable Components. As discussed, components are being offered
with pins having programable buffer strengths and having 3.3 and 5.0 levels.
Many other possiblilies exist.

(2) ASIC Design Configurations. Groups of Pins can be selected for
driving busses from a subset of model selections based on attributes such
as buffer strength and slew rate limits. The user would be responsible
for setting up the [Model Selector] keywords for each ASIC component

(3) Specific Usage of Standard Parts. Some users may standardize on
bi-directional components and use them also for input only or output only
configurations. Under these conditions, the [Component] model which the
contains I/O [Model](s) would be extended by the user for internal
usage to include, for example, Input and Output (or 3-state) [Model]
alternatives of the I/O [Model](s). The [Model Selector] syntax would list
these alternatives. The simulator checking could be reduced with proper
model selections when the bi-directional component is used in single
direction applications.

(4) Dynamically configurable buffers. I do not know whether on the fly
buffer modification for various modes of operation is often being done.
To do this requires the simulator to have a selection/reconfiguration
mechanism for complete support.

I look forward to more discussion on this at the Forum meetings and on the
reflector.

Bob Ross,
Interconnectix, Inc.
Received on Thu Aug 17 19:07:19 1995