BIRD 7 comment

Hello IBIS members:

Thanks, Kellee for the completed set of comments regarding Bird7.
You have presented a valid alternative proposal which saves adding
some new Model_types, yet produces the expanded functionality.

I think, however, "open-drain" is commonly understood to mean
open pullup for CMOS devices. I have never seen used to describe
an open pulldown configuration. I am open to any terminology
improvement, but agree with you that at least "Open_drain" should
be retained for compatiblity. Assuming "Open_source" is adopted,
I want to lay out a table with respect to a little item I introduced
and you commented on: 3-state open outputs.

The issue actually relates to the Vinh and Vinl Sub-Params of
[Model] and also to "Terminator" specification - issues Jon Powell
have raised in past Email. Assume we have the "open-source"
model_types and an additional one called "Terminator". Then a table
can be drawn providing reasonably complete coverage and consistency.

Model_type:

Terminator Output 3-state | I/O Input
              Open_drain 3-state_OD | I/O_Open_drain
              Open_source 3-state_OS | I/O_Open_source
                                       |
Vinh, Vinl not required | Vinh, Vinl required

                          | pullup and pulldown disable |
                          | option in simulator |
                          | (manual or automatic) |

Functionally there really is no need for any 3-state designation or
in many cases even the Output designation. The I/O designation
and the existence of Vinh and Vinl is sufficient to cover practical
modeling cases. The state that and I/O or 3-state model is in can be
external to the component. However, common data book terminology plus terms
used in IBIS Version 1.1 argue for Output and 3-state. So what I
am doing is just filling out the table for the "open" cases in a
consistent manner for explicit specification versus derived
specification, hopefully consistent with common practice. Furthermore,
I am reserving some Model_type words in case we really need them.

Actually, at this time I favor continuing making Vinh and Vinl
optional for all cases because I think some I/O models can be "disabled"
into a high Z mode without input. Furthermore, the Input could then
also designate a "terminator" functionality if Vinh and Vinl were not
specified. With Version 1.1, a diode terminator package such as
the SN74S1050 can be represented using Input models and the POWER_clamp
and GND_clamp data. However, for explicit specification, I would not
mind adding "Terminator" to the list of Model_types.

Briefly regarding terminators, I favor expanding the keyword list that
would be placed under [Model] to include [Rpower] and [Rgnd] for parallel
terminator specification and terminators to ground (and also pullup
resistors for open devices). Then a package such as the Motorala MCCS142233
9-Bit Switchable SCSI Passive Bus Terminator (220 Ohm and 330 Ohm) can
be modeled without using extended clamping data. Furthermore, I think
AC terminators should be modeled. Anyway, all of this is probably a
basis for another Bird per discussions next week.

This points out that a lot of issues are closely related, and getting
them all on the table will give a better overall resolution.

Bob Ross
Interconnectix, Inc.
Received on Fri Jan 21 16:06:55 1994