Subject: BIRD 7 comment

From: [email-masked] ( Bob Ross)
Date: Fri, 21 Jan 94 14:59:56 PST

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.