Subject: BIRD 30: Programmable Buffers

From: Will Hobbs <[email-masked]>
Date: Thu, 10 Aug 95 17:51:00 PDT

Text item: Text_1

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

DATE SUBMITTED:                       8-10-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 default buffer can be defined by a sub-parameter,
such as Default.

==============================================================================
|     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:  Default (?required if keyword used?)
| 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 sub-parameter Default is used to point to a default [Model]
|               to be used on the pin(s) calling 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
                ABCD0123456789ABCDE1
Default         ABCD0123456789ABCDE2
                ABCD0123456789ABCDE3
                ABCD0123456789ABCDE4
|
[Model selector]        Progbuffer2
                ABCD0123456789ABCDE0
Default         ABCD0123456789ABCDE3
                ABCD0123456789ABCDE4
                ABCD0123456789ABCDE5
                ABCD0123456789ABCDE6
******************************************************************************

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 charater for 
the user.  The main problem with this metod 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 preceeded 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 choises 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 untill 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 dharacterised.  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:

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

---

From: [email-masked] (Malan Rampton)
Date: Fri, 11 Aug 95 11:30:30 CDT

Dear Ibisians,

I applaud the intent of BIRD 30 to provide IBIS models with the
capability to handle programmable buffers in a more user friendly
manner. 

However, I do not believe that BIRD 30 takes this issue far enough. In
my experience as a signal integrity engineer most instances 
of programmable buffers have been encountered in the context of the
chip as a whole, or some subsection thereof, being programmable. A
simple example of this would be an ASIC that can be programmed to
function at either 5V or 3.3V levels. 

It therefore seems to me that what needs to be provided is a method
within IBIS to cleanly handle instances such as this: where a number
of signals (likely involving a number of different types of
programmable buffer) need to have correct buffer models selected based 
upon some characteristic, or set of characteristics. 

I have provided below a first pass at a sample syntax structure that
should suffice to provide the above capability. This is based 
upon the sample provided within the text of BIRD 30 and makes use of
the "Model selector" syntax that is laid out therein. The example
displays the selection of 3volt high drive buffers for a set of
target nets from two distinct programmable buffers and their
corresponding configuration sets.

In addition to the [Model selector] keyword I have added a [Signal
selector] keyword. This has syntax that is similar to that of [Model
selector] but provides a listing of nets that are programmed as a
set. A name for the net grouping also needs to be provided and a
default set of characteristics can be specified.

An optional sub-parameter "Classes" has also been added to
[Model]. This allows the specification of the programmable state of a
given model. A set of program classes are listed, i.e., voltage and
drive strength, and selection criteria values are assigned to them,
i.e., 5V or 3V and H or L. An open-ended number of classes may be
specified. 

In the example I have intentionally provided that the models of
Progbuffer1 are programmable for voltage and drive while the models of
Progbuffer2 are programmable only for voltage. In-spite of this they
have been grouped into the same [Signal selector] grouping. In a case
such as this, model selection should occur based upon what information
is present. If it is specified that 3volt high drive models are to be
selected for Progsection1 then the 3V H model from Progbuffer1 will be
used in conjunction with the 3V buffer from Progbuffer2.

Some miscellaneous notes: membership in more than one [Signal selector]
group for a net should be prohibited; also the selection
specifications MUST yield a unique model selection from each involved
[Model selector]; I have used signal names for the [Signal selector]
listing rather than pin names to provide for an easier conversion
among package types.

I believe that the additional functionality that this would provide is
probably worth the slightly greater complexity. I will brace myself to
hear otherwise, however.

**************************Begin Example*****************************
==============================================================================
|     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:  Default (?required if keyword used?)
| 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 sub-parameter Default is used to point to a default [Model]
|               to be used on the pin(s) calling 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		| voltage		drive
Default         ABCD0123456789ABCDE0	| 3V			H			
                ABCD0123456789ABCDE1	| 3V			L
	            ABCD0123456789ABCDE2	| 5V			H
                ABCD0123456789ABCDE3	| 5V			L
|
[Model selector]        Progbuffer2
                WXYZ9876543210WXYZE0	| 3V
Default         WXYZ9876543210WXYZE1	| 5V
|
[Signal selector]		ProgSection1	Default:voltage=3V;drive=H
				RAS0#,D0,D1,D2
|
|
|
[Model]		ABCD0123456789ABCDE0
Model_type	I/O
Classes		voltage=3V;drive=H			| optional parameter
Polarity	Non-Inverting
Enable		Active-Low
|  .
|  .
|  .
|
[Model]		ABCD0123456789ABCDE1
Model_type	I/O
Classes		voltage=3V;drive=L			| optional parameter
Polarity	Non-Inverting
Enable		Active-Low
|  .
|  .
|  .
|
[Model]		ABCD0123456789ABCDE2
Model_type	I/O
Classes		voltage=5V;drive=H			| optional parameter
Polarity	Non-Inverting
Enable		Active-Low
|  .
|  .
|  .
|
[Model]		ABCD0123456789ABCDE3
Model_type	I/O
Classes		voltage=5V;drive=L			| optional parameter
Polarity	Non-Inverting
Enable		Active-Low
|  .
|  .
|  .
|
[Model]		WXYZ9876543210WXYZE0
Model_type	I/O
Classes		voltage=3V					| optional parameter
Polarity	Non-Inverting
Enable		Active-Low
|  .
|  .
|  .
|
[Model]		WXYZ9876543210WXYZE1
Model_type	I/O
Classes		voltage=5V					| optional parameter
Polarity	Non-Inverting
Enable		Active-Low
|  .
|  .
|  .
|

regards,

Malan Rampton
Signal Integrity Group
Compaq Computer Corporation
phone: (713)374-6800
email: [email-masked]