******************************************************************************
******************************************************************************
BUFFER ISSUE RESOLUTION DOCUMENT (BIRD)
BIRD ID#: 88.2
ISSUE TITLE: Driver Schedule Initialization
REQUESTOR: Bob Ross, Teraspeed Consulting Group, Arpad Muranyi, Intel
DATE SUBMITTED: March 9, 2004
DATE REVISED: June 11, 2004, June 18, 2004
DATE ACCEPTED BY IBIS OPEN FORUM: Pending
******************************************************************************
******************************************************************************
STATEMENT OF THE ISSUE:
Each scheduled model under [Driver Schedule] has an initial state. These
initial states need to be explicitly stated for all permitted combinations
of numerical entries and NAs.
******************************************************************************
STATEMENT OF THE RESOLVED SPECIFICATIONS:
Changes in BIRD88.2 are shown with |** lines
Change the order of the last two paragraphs above Other Notes: and add an
initial state table.
Original:
| Use 'NA' when no delay value is applicable. For each
| scheduled model the transition sequence must be complete,
| i.e., the scheduled model must return to its initial state.
|
| No [Driver Schedule] table may reference a model which itself
| has within it a [Driver Schedule] keyword.
|
Revised:
| No [Driver Schedule] table may reference a model which itself
| has within it a [Driver Schedule] keyword.
|
| Use 'NA' when no delay value is applicable. For each
| scheduled model the transition sequence must be complete,
| i.e., the scheduled model must return to its initial state.
|
| Only certain numerical entry combinations are permitted to
| define a complete transition sequence. The table below gives
| the initial scheduled model states for each permitted set of
| numerical entries. The numerical delay entries, r, r1 and r2
| are relative to the internal simulator pulse rising edge, and
| f, f1 and f2 are the numerical delay entries relative to
| internal simulator pulse falling edge. For the cases where two
| delays are given relative to the same edge, the r2 entry is
| larger than the r1 entry, and the f2 entry is larger than the
| f1 entry. For cases below, the interchanging of such values
| corresponds to opposite direction switching. Once the
| scheduled model is set to its initial state, the switching
| is controlled by the internal simulator pulse and delays
| relative to it.
|
|* BIRD88 paragraph deleted and new paragraph below added.
|** The BIRD88.1 paragraph is below is deleted
|* In the table below the scheduled model initial states depend
|* on the initial state of the [Model]. This top-level [Model]
|* state ('Low' or 'High') is a function of the stimulus pulse
|* or simulation control method and the [Model] Polarity
|* subparameter. For example, if a [Model] Polarity is Inverting
|* and its stimulus pulse starts high and switches from high to
|* low, the [Model] initial state is 'Low' and all scheduled model
|* initial states follow the settings under the 'Low' column. The
|* four entry data ordering combinations omitted in the table are
|* disallowed because their initial states are ambiguous and the
|* rule to resolve this ambiguity would be equivalent to using one
|* of first two permitted combinations.
|** BIRD88.2 replacement paragraph showing revisions
|* In the table below the scheduled model initial states depend
|* on the initial state of the [Model]. This top-level [Model]
|* state ('Low' or 'High') is a function of the stimulus pulse
|** (or simulation control method) and the [Model] Polarity
|* subparameter. For example, if a [Model] Polarity is Inverting
|** and its stimulus pulse starts high,
|** the [Model] initial state is 'Low' and all scheduled model
|** initial states follow the settings under the 'Low' column. Two
|** possible four-entry data ordering combinations are omitted
|** because their initial states are ambiguous. Special rules to
|** select the initial states would just produce entry combinations
|** equivalent to those covered by the first two table entries.
|
| SCHEDULED MODEL INITIAL STATE TABLE
| -----------------------------------------------------------
| Table Numerical Delay Entries | [Model] Initial State
| Rise_on Rise_off Fall_on Fall_off | Low High
| -----------------------------------------------------------
| r NA f NA | Low High
| NA r NA f | High Low
| r1 r2 NA NA | Low Low
| r2 r1 NA NA | High High
| NA NA f1 f2 | High High
| NA NA f2 f1 | Low Low
| r1 r2 f2 f1 | Low Low
| r2 r1 f1 f2 | High High
| -----------------------------------------------------------
|
|** BIRD88.2 statement added:
|** The delay numbers r, r1, r2, and f, f1, f2 plus the associated
|** model transitions should fit within the corresponding pulse width
|** durations. Smaller pulse width stimuli may change the switching
|** sequencing and is not supported.
|**
|* BIRD88 paragraph below the table deleted and last paragraph about
|* [Diff Pin] deleted.
|
******************************************************************************
ANALYSIS PATH/DATA THAT LED TO SPECIFICATION
When the [Driver Schedule] keyword was introduced in BIRD35.3, it added
scheduled models under the [Model] keyword. The intent was to craft the
scheduled model operations without changing any existing [Model] keyword
rules of operation. One common application of IBIS was to describe a
single edge switching operation or to do timing relative to only the first
rising or falling transition. The [Model] keyword supported such operation.
Both the rising and falling waveforms were supplied, and the control
mechanism (pulse control table or stimulus) along with the Polarity
subparameter gave the necessary [Model] starting state (and corresponding
information regarding which direction to switch).
The newly introduced [Driver Schedule] syntax supported, under its four
columns, sixteen combinations for numerical delay and NA entries. However
some statements constrained what combinations were allowed, and a cryptic
general rule carried major implication:
"For each scheduled model the transition sequence must be complete,
i.e., the scheduled model must return to its initial state."
This rule was intended convey the notion that within one complete
[Model] switching cycle, each scheduled model also needed to describe
a switching sequence that returned each scheduled model to its initial
state. So the implied, but unstated assumption was that each scheduled
model had a deterministic initial state. Thus the overall [Model]
containing scheduled models still had an overall initial state based
on the combination of scheduled model initial states.
Some combinations of delay entries complied with the above rule, but
actually described opposite direction switching from that implied at
the top-level. This was regarded as a benefit, and some examples
demonstrated this.
BIRD58.3 added a clarification to specify exactly the allowed syntactical
combinations:
| The [Driver Schedule] table consists of five columns. The
| first column contains the model names of other models that
| exists in the .ibs file. The remaining four columns describe
| delays: Rise_on_dly, Rise_off_dly, Fall_on_dly, and
| Fall_off_dly. The t=0 time of each delay is the event when
| the EDA tool's internal pulse initiates a rising or falling
| transition. All specified delay values must be equal to or
| greater than 0. There are only five valid combinations in
| which these delay values can be defined:
|
| 1) Rise_on_dly with Fall_on_dly
| 2) Rise_off_dly with Fall_off_dly
| 3) Rise_on_dly with Rise_off_dly
| 4) Fall_on_dly with Fall_off_dly
| 5) All four delays defined
| (be careful about correct sequencing)
Together, these statements implied that each model must contain relative
delays to "initiate" either two or four transitions within a complete
cycle. They continued to imply that the initial state could be determined.
Because the interpretation can be ambiguous, this BIRD adds the details
concerning how an initial state is determined, as originally intended.
The overall [Model] control remains unchanged regarding whether it contains
any [Driver Schedule] information for these situations:
- Completely deterministic first half cycle (rising edge or falling edge
only) simulation
- Similar results in subsequent cycles
- Differential buffer operation still supported (same model can be used
for both pins)
Thus a model with pre-/de-emphasis could be correctly modeled in differential
mode for the first half cycle. An example is LVDS technology.
The permitted cases are entered into the specification. The other cases that
are illegal are listed:
| REMAINING ILLEGAL SCHEDULED MODEL CASES
| ------------------------------------------------------------
| Table Numerical Delay Entries | Reason
| Rise_on Rise_off Fall_on Fall_off |
| ------------------------------------------------------------
| NA NA NA NA | Unknown Intial State
| r NA NA f | Up-Up Sequencing
| NA r f NA | Down-Down Sequencing
| r1 r2 f1 f2 | Up-Down-Down-Up Seq.
| r2 r1 f2 f1 | Down-Up-Up-Down Seq.
| One or three numerical entries | Sequencing Incomplete
| ------------------------------------------------------------
For the same successive sequencing, the presumed initial state differs from
the ending state. A full cycle is not given, and the initial state is
ambiguous. This can cause some first cycle simulations to be different than
the subsequent cycles in EDA tools that allow such conditions.
For example, the r1 r2 f1 f2 case (Up-Down-Down-Up) scheduled model low:
r1: low-to-high
r2: high-to-low
f1: redundant high-to-low starting after the falling edge reference
f2: low-to high (ends high and differs from the start)
Note, the second cycle and subsequent cycles start high, and end high
or if schedule model starts high with
f1: high-to-low
f2: low-to-high
r1: redundant low-to-high after the rising edge reference
r2 high-to-low (ends low and differs from the start)
Note, the second cycle and subsequent cycles start low and end low
So the ending state does not always match the starting state, and the second
cycle may have a different sequence of operations. This violates how
[Model] should behave because now ALL first cycle simulations would be
suspect.
An allowed case is r1 r2, f2 f1, starting low or high according the
to the Initial State setting and next edge works fine:
r1: low-to-high ([Model] low, scheduled model initial state low)
r2: high-to-low
f1: low-to-high (or [Model] high, scheduled model initial state low)
f2: high-to-low
The same "complete" cycle argument is used for the other accepted or
rejected sequences. This accepted sequences then are consistent with all
other existing [Model] interactions internal simulator pulse or stimulus,
[Model] Polarity, and [Diff Pin] operation.
All of the above settings assume sufficiently long half cycle times for the
transitions to be initiated and completed in a normally clocked manner
without any overclocking truncation.
BIRD88.1:
Changes were based on private comments/corrections from Arpad Muranyi.
The editorial corrections were adopted.
The two paragraphs above and below the table were somewhat redundant and
have been combined to one paragraph above the table:
Deleted:
| The scheduled model initial states are related to the intial
| state of the [Model]. This top-level [Model] initial state
| is a function of both the internal simulator pulse (or
| stimulus) and/or the top-level [Model] Polarity setting.
and
| Note the initial [Model] state (Low or High) can be a function
| of the stimulus pulse or simulation control method and the
| [Model] Polarity subparameter. For example, a stimulus pulse
| starting at the High state and switching from high to low
| that drives a [Model] with a Polarity set at Inverting means
| that the [Model] initial state is Low, and the scheduled
| model initial states follow the settings under the Low column.
|
Also a paragraph concerning differential pins is deleted because it is
not really relevent to this section:
Deleted:
| The [Diff Pin] sets up each [Model] keyword it references
| to the [Model] initial state setting in the same manner
| with or without any [Driver Schedule] keyword.
|
Per some additional private explainations, certain four entry data
combinations are not allowed. In order to comply with the full cycle
rule, while being compatible to the next encountered edge, the disallowed
combinations would have to be initialized in a manner that would map
directly into some existing two entry combinations. Specifically:
| REMAINING ILLEGAL SCHEDULED MODEL CASES
| ------------------------------------------------------------
| Table Numerical Delay Entries | Reason
| Rise_on Rise_off Fall_on Fall_off |
| ------------------------------------------------------------
| r1 r2 f1 f2 | Up-Down-Down-Up Seq.
Maps to NA r NA f
| r2 r1 f2 f1 | Down-Up-Up-Down Seq.
Maps to r NA f NA
| ------------------------------------------------------------
It is easier to disallow the combinations than to document the exceptions.
There is no loss in functionality.
BIRD88.2
Editorial cleanup per Arpad Muranyi's suggestion and statement about delay
size.
******************************************************************************
ANY OTHER BACKGROUND INFORMATION:
BIRD85.3 introduced [Driver Schedule]. BIRD58.3 and BIRD84.1 added some
clarifications related events and states. However, the added language did
not address the initial settings. In fact, some of the language could be
the basis for arguing a first encountered state change approach for any
initial setting and causing the first cycle to differ with the remaining
cycles.
Driver Schedule operation was discussed in IBIS Summit presentations on
February 2, 2004 (muranyi3.pdf, ross2.pdf) and during earlier meeting on
June 21, 2001 (reid.pdf, and several others). The reid.pdf presentation
shows an EDA vendor implimentation that correctly sets the initial states
for the first half cycle for several of the cases given in the table.
http://www.eda.org/pub/ibis/summits/
Some other added keywords related to Submodels either have explicit
syntax contraints or direct statements to specify the initial states.
So the convention that the [Model] keyword provides the overall initial
state is preserved.
BIRD88.1 is submmitted in response to some private suggestions and to fix
some minor editorial errors discovered in BIRD88.
BIRD88.2 is submmitted with editorial improvements suggested by Arpad
Muranyi.
******************************************************************************
******************************************************************************