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.

******************************************************************************
Received on Tue Oct 3 16:52:14 1995