Subject: [IBIS-Users] BIRD83 - Series Element Clarifications
From: Mirmak, Michael (michael.mirmak@intel.com)
Date: Wed Sep 17 2003 - 11:46:36 PDT
All,
BIRD83 is enclosed for review.
- Michael Mirmak
Intel Corp.
Chair, EIA/IBIS Open Forum
************************************************************************
*****
************************************************************************
*****
************************************************************************
*****
BUFFER ISSUE RESOLUTION DOCUMENT (BIRD)
BIRD ID#: 83
ISSUE TITLE: Series Element Clarifications
REQUESTOR: Michael Mirmak, Intel Corporation
DATE SUBMITTED: September 17, 2003
DATE REVISED:
DATE ACCEPTED BY IBIS OPEN FORUM: Pending
************************************************************************
*****
************************************************************************
*****
STATEMENT OF THE ISSUE:
Ambiguous language in the IBIS 4.0 specification can lead to mutually
exclusive but text-compliant descriptions of series element behaviors.
The issues are:
a) the presence of the function_table_group column under the [Series Pin
Mapping] keyword implies that a series switch is being described.
However,
the presence of the function_table_group column does not require the
use of the [Series Switch Group] keyword to describe the corresponding
series switch groupings
b) the language of [Series MOSFET] does not explicitly require that
the [Series MOSFET] keyword be used before each occurrence of the Vds
subparameter and I-V table data. This implies that both a single
[Series MOSFET] keyword instance or multiple instances may be used to
describe the same device regardless of the number of I-V tables present
To address these issues, two changes are proposed:
a) if "function_table_group" is present under [Series Pin Mapping], the
[Series Switch Groups] keyword is required
b) the [Series MOSFET] keyword is explicitly required before each Vds
subparameter
The changes noted above are consistent with the behavior of version
3.2.9
of the IBIS Golden Parser.
Several minor grammatical issues have also been resolved in the proposed
text below. Note that the examples have been omitted.
************************************************************************
****
STATEMENT OF THE RESOLVED SPECIFICATIONS:
Changes are marked with the * characters.
|=======================================================================
======
| Keyword: [Series Pin Mapping]
| Required: No
| Description: Used to associate two pins joined by a series model.
| Sub-Params: pin_2, model_name, function_table_group
| Usage Rules: Enter only series pin pairs. The first column, [Series
Pin
| Mapping], contains the series pin for which input
impedances
| are measured. The second column, pin_2, contains the
other
| connection of the series model. Each pin must match the
pin
| names declared previously in the [Pin] section of the
IBIS
| file. The third column, model_name, associates the
Series or
| Series_switch model for the pair of pins in the first
two
| columns. The fourth column, function_table_group,
contains
| an alphanumeric designator string to associate those
sets of
| Series_switch pins that are switched together.
|
| Each line must contain either three or four columns.
When
| using four columns, the header function_table_group must
be
| listed.
|
| One possible application is to model crossbar switches
where
| the straight through On paths are indicated by one
designator
| and the cross over On paths are indicated by another
| designator. If the model referenced is a Series model,
then
| the function_table_group entry is omitted.
|
*| Note that, if the function_table_group entry is used,
the
*| [Series Switch Groups] keyword must be present and
contain
*| switching combination definitions corresponding to the
*| function group entries.
| The column length limits are:
| [Series Pin Mapping] 5 characters max
| pin_2 5 characters max
| model_name 20 characters max
| function_table_group 20 characters max
|
| Other Notes: If the model_name is for a non-symmetrical series model,
| then the order of the pins is important. The [Series
Pin
| Mapping] and pin_2 entries must be in the columns that
| correspond with Pin 1 and Pin 2 of the referenced model.
|
| This mapping covers only the series paths between pins.
The
| package parasitics and any other elements such as
additional
| capacitance or clamping circuitry are defined by the
| model_name that is referenced in the [Pin] keyword. The
| model_names under the [Pin] keyword that are also
referenced
| by the [Series Pin Mapping] keyword may include any
legal
| model or reserved model except for Series and
Series_switch
| models. Normally the pins will reference a [Model]
whose
| Model_type is 'Terminator'. For example, a
Series_switch
| model may contain Terminator models on EACH of the pins
to
| describe both the capacitance on each pin and some
clamping
| circuitry that may exist on each pin. In a similar
manner,
| Input, I/O or Output models may exist on each pin of a
Series
| model that is serving as a differential termination.
|
[...]
|
|=======================================================================
======
| Keyword: [Series Switch Groups]
*| Required: Yes, if function_table_group is used under
*| [Series Pin Mapping]
| Description: Used to define allowable switching combinations of
series
| switches described using the names of the groups in the
| [Series Pin Mapping] keyword function_table_group
column.
| Sub-Params: On, Off
| Usage Rules: Each state line contains an allowable configuration. A
| typical state line will start with 'On' followed by all
of the
| on-state group names or an 'Off' followed by all of the
| off-state group names. Only one of 'On' or 'Off' is
required
| since the undefined states are presumed to be opposite
of the
| explicitly defined states. The state line is terminated
with
| the slash '/', even if it extends over several lines to
fit
| within the 80 character column width restriction.
|
| The group names in the function_table_group are used to
| associate switches whose switching action is
synchronized by
| a common control function. The first line defines the
assumed
| (default) state of the set of series switches. Other
sets of
| states are listed and can be selected through a user
interface
| or through automatic control.
|-----------------------------------------------------------------------
------
[...]
|=======================================================================
======
| Keyword: [Series MOSFET]
| Required: Yes, for series MOSFET switches
| Description: The data points under this keyword define the I-V tables
for
| voltages measured at Pin 2 for a given Vds setting.
Currents
| are considered positive if they flow into Pin 1. Pins 1
and
| 2 are listed under the [Series Pin Mapping] keyword
under
| [Series Pin Mapping] and pin_2 columns, respectively.
| Sub-Params: Vds
| Usage Rules: The first column contains the voltage value, and the
three
| remaining columns hold the typical, minimum, and maximum
| current values. The four entries, Voltage, I(typ),
I(min),
| and I(max) must be placed on a single line and must be
| separated by at least one white space.
|
*| All four columns are required under this keyword.
However,
| data is only required in the typical column. If minimum
| and/or maximum current values are not available, the
reserved
| word "NA" must be used. "NA" can be used for currents
in the
| typical column, but numeric values MUST be specified for
the
| first and last voltage points on any I-V table. Each
I-V
| table must have at least 2, but not more than 100 rows.
|
| Other Notes: There is no monotonicity requirement. However the model
| supplier should realize that it may not be possible to
derive
| a behavioral model from non-monotonic data.
|
|
| Table Current
| -------> Ids
| + Vds -
|
| Vcc
| | g
| __|__
| ----- NMOS
| Pin 1 | | Pin 2
| <---+ +---> + Voltage = Vcc - Vs
| d |_____| s
| PMOS --+-- Vs
| | g
| GND -
|
*| Either of the FETs could be removed (or have zero
current
*| contribution). Thus this model covers all four
conditions,
| off, single NMOS, single PMOS and parallel NMOS/PMOS.
|
| Voltage = Table Voltage = Vtable = Vcc - Vs
| Ids = Table Current for a given Vcc and Vds
|
| Internal Logic that is generally referenced to the power
rail
| is used to set the NMOS MOSFET switch to its 'ON' state.
| Internal logic likewise referenced to ground is used to
set
| the PMOS device to its 'ON' state if the PMOS device is
| present. Thus the [Voltage Range] settings provide the
| assumed gate voltages. If the [POWER Clamp Reference]
exists,
| it overrides the [Voltage Range] value. The table
entries are
| actually Vgs values of the NMOS device and Vcc - Vgs
values of
| the PMOS device, if present. The polarity conventions
are
| identical with those used for other tables that are
| referenced to power rails. Thus the voltage column can
be
| viewed as a table defining the source voltages Vs
according to
| the convention: Vtable = Vcc - Vs. This convention
remains
| even without the NMOS device.
|
| If the switch is used in an application such as
interfacing
| between 3.3 V and 5.0 V logic, the Vcc may be biased at
a
| voltage (such as 4.3 V) that is different from a power
rail
| voltage (such as 5.0 V) used to create the model. Just
| readjust the [Voltage Range] entries (or [POWER Clamp
| Reference] entries).
|
| One fundamental assumption in the MOSFET switch model is
that
| it operates in a symmetrical manner. The tables and
| expressions are given assuming that Vd >= Vs. If Vd <
Vs,
| then apply the same relationships under the assumption
that
| the source and drain nodes are interchanged. A
consequence of
| this assumption is that the Vds subparameter is
constrained to
| values Vds > 0. It is assumed that with Vds = 0 the
currents
| will be 0 mA. A further consequence of this assumption
that
| would be embedded in the analysis process is that the
voltage
| table is based on the side of the model with the lowest
| voltage (and that side is defined as the source). Thus
the
| analysis must allow current to flow in both directions,
as
| would occur due to reflections when the switch is
connected in
| series with an unterminated transmission line.
|
| The model data is used to create an On state
relationship
| between the actual drain to source current, ids, and the
| actual drain to source voltage, vds:
|
| ids = f(vds).
|
| This functional relationship depends on the actual
source
| voltage Vs and can be expressed in terms of the
corresponding
| table currents associated with Vs (and expressed as a
function
| of Vtable).
|
| If only one [Series MOSFET] table is supplied (as a
first
| order approximation), the functional relationship is
assumed
| to be linearly related to the table drain to source
current,
| Ids, for the given Vds subparameter value and located at
the
| existing gate to source voltage value Vtable. This
table
| current is denoted as Ids(Vtable, Vds). The functional
| relationship becomes:
|
| ids = Ids(Vtable, Vds) * vds/Vds.
|
*| More than one [Series MOSFET] table under a [Model]
keyword
*| is permitted. However, the usage of this data is
simulator
*| dependent. Each table must begin with the [Series
MOSFET]
*| keyword and Vds subparameter. Each successive
*| [Series MOSFET] table must have a different
subparameter
*| value for Vds. The number of tables for any specific
*| [Model] must not exceed 100.
|
| C_comp values are ignored for [Series MOSFET] models.
************************************************************************
*****
ANALYSIS PATH/DATA THAT LED TO SPECIFICATION:
************************************************************************
*****
ANY OTHER BACKGROUND INFORMATION:
************************************************************************
*****
|------------------------------------------------------------------
|For help or to subscribe/unsubscribe, email majordomo@eda.org
|with just the appropriate command message(s) in the body:
|
| help
| subscribe ibis <optional e-mail address, if different>
| subscribe ibis-users <optional e-mail address, if different>
| unsubscribe ibis <optional e-mail address, if different>
| unsubscribe ibis-users <optional e-mail address, if different>
|
|or email a written request to ibis-request@eda.org.
|
|IBIS reflector archives exist under:
|
| http://www.eda.org/pub/ibis/email_archive/ Recent
| http://www.eda.org/pub/ibis/users_archive/ Recent
| http://www.eda.org/pub/ibis/email/ E-mail since 1993
This archive was generated by hypermail 2b28 : Wed Sep 17 2003 - 11:48:40 PDT