****************************************************************************** ****************************************************************************** BUFFER ISSUE RESOLUTION DOCUMENT (BIRD) BIRD ID#: 88.3 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, June 21, 2004 DATE ACCEPTED BY IBIS OPEN FORUM: July 16, 2004 ****************************************************************************** ****************************************************************************** STATEMENT OF THE ISSUE: Changes in BIRD88.2 are shown with |** lines. Changes in BIRD88.3 are shown with |*** lines. 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: 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 and BIRD88.3 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-data ordering combinations are omitted because |*** their initial states are ambiguous. Special rules to select the |*** initial states would produce sequencing equivalent to the |*** two-data combinations shown in the first two lines of the table. | | 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. BIRD88.3 The last two sentences of a BIRD88.2 paragraph are revised. The deleted sentences are shown: |** 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. ****************************************************************************** ANY OTHER BACKGROUND INFORMATION: BIRD35.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. BIRD88.3 is submmitted with an editorial revision. ****************************************************************************** ******************************************************************************