Subject: BIRD 5.1

From: Bob Ward <[email-masked]>
Date: Wed, 15 Dec 1993 15:44:42 -0600

I have been looking at BIRD 5.1 and have a few comments, mostly minor.

I am thinking that the use of NA for the state of not being connected to a
power or ground bus would be better cast as NC.  The present day buzzword for
the use of NA is "overloading" where in one context it means Not Available
and in another it mean Not Connected.  I would think that the semantic change
is less if we use NC with all the same rules as for NA.  Just one of those
little consistencies that make writing parsers more tolerable.

For effective power and ground bounce work one really should not ignore
mutual couplings.  These can be really significant in some cases.  Now the
statement that this BIRD allows for first order analysis ( I would add 'at
least' since it could go a long way toward second order as well ) probably
says that we do not need mutuals yet.  I am at a loss just now as to whether
these should be saved for a later BIRD or whether we should try to factor
them in here.  Doing so would affect quite a few things.

Advice or comments?

Thanks,

=============================================================================

     __                          /             
    /  \                  /     /                     Bob Ward
   /__ /        /        /  /  /            /   MSG:  SQU       
  /    \  _    /_       /  /  /  _   __  _ /   INET:  [email-masked]
 (____ / (_)_ /__)     (__(__/  (_(_/ (_(_/           713+274-4146 Voice
                                                      713+274-3911 Fax

=============================================================================

---

From: [email-masked]
Date: Wed, 15 Dec 93 17:35:58 -0500

An open letter:

Bob,

  Now that you mention it, I think "NC" is better, too. It will avoid
confusion about what has to be specified.  (I'd hate for someone to
think that the pin mapping was simply unavailable...)

  Look for BIRD 5.2 with this amendment shortly.

  With regard to mutuals:  I think that the issue is orthogonal to that
of the pin mapping.  That is, if the pins have mutual couplings to one
another, they can be specified independently of the pin mappings, as 
long as we exclude from consideration the very general network 
topologies (like the one you described in that famous mail message
of a week or two ago.)  The [Pin_Mapping] isn't meant to handle those
problems anyway, at least not in a rigorous fashion.

  If we come up with a spec for describing the pin-to-pin mutual
couplings (I'd still like to do this), then it's straightforward to
extend the concept of "parallel combination" to determine the
impedances seen looking out into the board from the devices connected
to the bus.

  In fact, now that we're talking about it, here's an EGG (even
earlier than a BIRD) on how to do mutuals:

[Mutuals]	Pin1	Pin2	Rmut	Lmut	Cmut
		1	2	1e-3	1n	1p
		1	3	1e-4	0.1n	0.1p

Columns "Pin1" and "Pin2" contain numbers of pins which are coupled
together; the Rmut, etc. columns specify the values of the couplings.

Not every coupling must be specified (in the interest of sparsity);
you can assume that the self-inductances have been specified in the
[Pin] section (talk about backward compatibility!)  And it all fits
into 80 characters.

The only thing I'm not sure about here is where the C is; is it on
the "outside" node (close to the board) or the inside node (near the
die)?  

Kumar, or Chris, do you have an opinion on where C should be?

--Eric Bracken