Re: BIRD 58

From: Matthew Flora <mbflora@hyperlynx.com>
Date: Wed Mar 24 1999 - 04:29:11 PST

Arpad,

Since you are submitting BIRD 58 as a clarification to the [Driver Schedule]
keyword, I was wondering if you could add to the BIRD.

From the spec/BIRD:
     "Only the [Pulldown] and [Pullup] tables and transition data
      [Ramp] or [Rising Waveform] and [Falling Waveform] data are
      used from each model that is referenced. The [Model] keyword
      provides the specification information, [GND Clamp] and [POWER
      Clamp], and C_comp, regardless of information contained in
      the referenced models."

1) In the above excerpt, it says "The [Model] keyword provides the
   specification information, ...". Should that instead say "The top-level
   model provides the specification information, ..."?

2) The excerpt above does not explicitly say which [Voltage Range] and/or
   [Pullup Reference], [Pulldown Reference] is to be used. My interpretation
   is that the referenced models use the voltage range/references from the
   top-level model. Perhaps someone else would interpret it differently. I'd
   like the spec to explicitly say which voltage range/references are to be
   used with the [Pulldown] and [Pullup] tables taken from the referenced
   models.

From the spec/BIRD:
     "It is recommended that a "golden waveform" for the device
      consisting of a [Rising Waveform] table and a [Falling
      Waveform] table be supplied under the [Model] keyword to
      serve as a reference for validation."

3) In the above excerpt, it says "... table be supplied under the [Model]
   keyword to serve as a reference for validation.". Should that instead say
   "... table be supplied within the top-level model to serve as a reference
   for validation."?

From the spec/BIRD:
     "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
      Falling_off_dly. All values are referenced to 0 seconds for
      the start of the rising transition and 0 seconds for the start
      of the falling transition. All delays must be equal to or
      greater than 0.

      The Rise_on_dly entry gives the beginning of the low-to-high
      transition. The Rise_off_dly entry may be given to end the
      low-to-high transition and initiate a high-to-low transition
      during the rising cycle. Similarly, the Fall_on_dly gives
      the beginning of the high-to-low transition. The Fall_off_dly
      may be given to end the high-to-low transition and initiate a
      low-to-high transition.

      Use 'NA' when no transition is applicable. For each model,
      the transition sequence must be complete, i.e., it must start
      and end at the same state."

I'm sorry, but I find this whole section confusing.

4) It appears that the intent of the keyword is to allow the drive strength of
   an output buffer to be increased or decreased by adding in (and/or taking
   out) various tables from other models at strategic times during the
   transitioning of the buffer's output. Is this intent stated in the spec?

5) The above excerpt refers to transitions and a rising cycle. When is the
   text referring to the transition (cycle) of the output of the buffer as a
   whole versus the transition (cycle) of the added "boost" model?

6) If the Rise_on_dly and Rise_off_dly specify the start of the added "boost"
   model's rising edge and falling edge, respectively, then the example shows
   "boost" models (MODEL_OUT, M_O_SOURCE1) which turn on, but not off during
   the rising transition of the output buffer. Yet the excerpt above says
   "For each model, the transition sequence must be complete, i.e., it must
   start and end at the same state." This strikes me as a contradiction.

7) Must at least one of the delay times be specified or can all four be NA?

I also noticed some typos in the spec/BIRD:

1) In one place the spec refers to "Falling_off_dly" instead of
   "Fall_off_dly".

2) "... other models that exists in the .ibs file." The "exists" should be
   "exist".

Now I realize that I may have a misunderstanding of the intent and/or the
workings of the [Driver Schedule] keyword. If I do, then I would suggest that
the definition of the keyword is not clear enough.

Regards,
Matthew Flora
IBIS Open Forum Secretary
(425) 869-2320 PH
(425) 881-1008 FAX
mbflora@hyperlynx.com
HyperLynx, 17641 NE 67th Court, Redmond, WA 98052 USA
Received on Wed Mar 24 11:34:41 1999

This archive was generated by hypermail 2.1.8 : Fri Jun 03 2011 - 09:52:30 PDT