Comments and questions about Electrical Descriptions of Boards and Connectors.

From: Dileep Divekar <dileep@contec.Apsimtech.COM>
Date: Tue Nov 05 1996 - 18:32:26 PST

I have some comments and questions about the BIRD regarding the
Electrical Descriptions of Boards and Connectors.

1)
| Note: The simulator must not limit the Number of Pins to any
| value less than 1,000.
I do not understand why any number should be specified. If the maximum
allowable limit is 1,000 then many high pin count packages cannot be
modeled.

2)
|Description: Tells the parser the set of names that are used for the part's
| external pins and also defines pin ordering. The first pin name
| given is the "lowest" pin, and the last pin given is the
| "highest".
I do not understand the significance of this. Why is it necessary to define
pin ordering? The parser needs only the information about pin names.

3)
| R The series DC (ohmic) resistance of a section, in
| terms of ohms per unit length.
I think in addition to R, specification of G should be allowed. Since this
is an optional specification, for cases where the dielectric loss is not
significant, it need not be specified. In fact I would say that we should
go even one step further and allow an optional sepcification of high frequency
R in addition to the DC value.

4)
| A section description begins with the Len subparameter and
| ends with the backslash (/) character. The value of the Len, L,
The backslash (/) character mentioned above is actually a forward slash
character. The backslash is \.

5)
| A) Len, and one or more of the L, R and C subparameters. If
| the Len subparameter is given as zero, then the L/R/C sub-
| parameters represent lumped elements. If the Len subparameter
| is non-zero, then the L/R/C subparameters represent distributed
| elements.
I think the specification should say that if non-zero Len is specified,
then BOTH L AND C MUST be specified. The R (and G) can be optional.
By definition, the physical description of the distributed transmission
line has BOTH L and C.

6)
| B) The first subparameter following the [Path Description]
| keyword must be 'Pin', followed by one or more section
| descriptions. The path description can terminate in a node,
| section, another pin or the reserved word, NC.
|
| C) All paths and subpaths (a path between Fork and Endfork)
| end in a Pin, a Node or NC.
The last sentence in B) and the sentence in C) seem contradictory. B) allows
the path to be terminated in a section also. The only possible subparameters
under the path description are Len, Pin, Node and Fork/EndFork. I do not see
any need to put restrictions on how the path should end. Also, the need and
usage of NC is not clear. Off hand, it seems that we can do without it.
Is it allowed to have another Fork statement inside a Fork statement before
the Endfork?

7)
| Node pin.reference_designator
This is a minor point, but all the pcb design programs I know, use the
convention reference_designator.pin. Most people are used to seeing
something like U3.17 as opposed to 17.U3.

Some general comments:

There are cases where a trace forks into two and then the two traces join
again to form a single trace. How does one describe this?

It is stated that C is the capacitance to "ground". This assumes that there
is only ONE ground for ALL the sections of this board as well as all the
other boards connected to this board by virtue of .eid models specified
in the Reference Designator Map. This precludes the use of this model
for doing ground bounce analysis.

Since this is supposed to address the full board description, I just wanted
to mention that there is a tendency (particularly in SIMMs and MCMs) to add
other components on the boards, in addition to the ICs and connectors.
Embedded resistors is an example that comes to mind. Is it possible to
include these components in this description?

Dileep
------------------------------------------------------------
Dileep Divekar
Applied Simulation Technology, Inc.
2188 Bering Drive
San Jose, CA 95131

Phone - (408)-434-0967 x 100
Fax - (408)-434-1003
Email - dileep@apsimtech.com
------------------------------------------------------------
Received on Wed Nov 6 12:01:51 1996

This archive was generated by hypermail 2.1.8 : Fri Jun 03 2011 - 09:52:29 PDT