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 12:11:52 1996