Re: Bird 35

Jon and IBIS Committee:

Eventually examples with numerical tables will be needed to support some
our observations. A brief response to your comments is:

(1) While perhaps not stated, my intention was to support through individual
Waveform tables the capability of turning on and off a particular internal
driver. Also, a particular stage could function in just the rising or
falling direction only. The [Rising Waveform(x)] table of stage x could
go from low to high and then return to the low state. The [Falling
Waveform(x)] table could just be held constant at the low state.

Also my intention was to allow [Pullup(x)] or [Pulldown(x)] only stages.

(2) You make a point that a scheduling table could be considered to define
the relative phasing of the stages. It would be clearer to have this
information in one area and allow easier adjustment to match the internal
phasing activity with a know external response. The actual rise/fall time
shapes are still in the Waveform tables. So I expect to have some scheduling
syntax. The scheduling could still work withing the BIRD35 proposal to
schedule the internal stages. One stated preference was to group the
information in one [Model] versus just scheduling several existing models.

One of the aspects of the proposed grouping and restrictions is to avoid
having duplicate characteristics in the model. Thus the [Power Clamp]
and [Gnd Clamp] tables appear only once. Similarly for the [Model]
subparameters. The package characteristics would apply just to the
total model.

Bob Ross
Interconnectix, Inc.

> Date: Wed, 12 Jun 96 11:16:26 PDT
> From: jonp@qdt.com (Jon Powell)
> To: ibis@vhdl.org
> Cc: jonp@qdt.com, bob@icx.com
> Subject: Bird 35

> Bob et al.

> I just read bird 35 and have the following observations:

> 1)There is one functionality that appear to be missing and that is a way
> to shut OFF a driver during a rising (or falling edge). There is a class of
> drivers that turn on at 0 but then one driver turns off a few nanoseconds later.

> 2) I think that a much easier way of organizing this data would be for the
> new construct to refer to existing device models (that already have their own
> pull-ups and VT arrays) and then just specify their relative scheduling.

> for instance: (with no particular syntax implied)

> DRIVER MASTER_OUT
> SUB_DRIVER FAST_OUT_1 turn_on_rising: .3ns turn_off_rising: 1.0ns turn_on_falling: 0.0 turn_off_falling: NONE
> SUB_DRIVER FAAST_OUT_2 turn_on_rising: 0.0 turn_off_rising: NONE turn_on_FALLING: 0.0 turn_off_falling: 1.0
> etc

> the NONE means that that device never turns off (until the next state change).

> If sub_models only have pullup or pulldown components, then they would be defined the same as open-collector etc.

> All parameters of each of the standard drivers are inherited (if they make sense) and this master driver would contain
> the parameters that only make sense for the outside device (like the package paramters).

> I think this is easier to understand and easier to model since now each of the sub_drivers can be extracted
> using existing IBIS methodology.

> regards,
> jon
Received on Wed Jun 12 18:59:27 1996