Subject: IBIS Comments and questions about Electrical Descriptions of Boards and Connectors

From: [email-masked] ( Bob Ross)
Date: Fri, 8 Nov 96 11:30 PST

To IBIS Committee:

Here is an apparently bounced message that was supposed to go out
to the IBIS committee that was not sent.  Sorry about the format.
This was how it was received, plus some extra binary stuff at the
end which I deleted.  (Hank had indicated some mailer changes.)

Bob Ross
Interconnectix

Dileep,

I am happy that someone is really reading this material.  Thank you for 
your questions and comments.  My response is provided below, following 
each one of your questions or comments.

----------
From: 	owner-ibis[SMTP:[email-masked]]
Sent: 	Wednesday, November 06, 1996 10:32 AM
To: 	ibis
Cc: 	dileep
Subject: 	Comments and questions about Electrical Descriptions of 
Boards and Connectors.

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.
The only reason any number is specified is to prevent an arbitrary 
limit from being set by a simulator.  For example, it would be a 
problem if this value was limited to an 8 bit integer.

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.
There needs to be a way for the simulator to match external, or global 
pin names to the internal pin names used in the model.  This is 
especially important in the case of connectors where there are 2 ends 
to every contact that need to be appropriately identified and properly 
connected to the rest of the system.  That is the purpose of this 
statement and it is in agreement with the way it is handled in IBIS 
version 2.1 (I hope).

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.
I do not see any reason that G can not be included as an additional 
option.  I do have some concerns about trying to specify a HF R.
	1.  First, I would point out that we are dealing with uncoupled models
		at this time and are after fast, first order accuracy.
	2.  What frequency would you use for a digital signal and how
		would that R be calculated?
	3.  There would be a need to specify a frequency (or bandwidth) for
		any non-DC resistance.
	4.  Finally, with respect to connectors in digital signal 
applications,
		skin effects are negligible, especially for this first order
		modeling we are pursuing here, and we want the proper
		voltage drop across the connector for any DC circuit.

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 \.
Good point!  Got me on that one!  I think it should be the 'slash' (/), 
not the 'backslash' (\).  Our syntax experts should check that out.

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.
Another good point.  I think this can be fixed by the addition of "and 
at least L and C must be specified" to the end of the last sentence.

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?
The NC and the need for a specific end to a path description covers 
situations where there may be a stub on a board or a skipped or deleted 
pin on a connector where there is more than one pin for a given contact 
such as for a shielding plate.  I do see your contradiction, however. 
 Perhaps the word 'section' should be deleted from B) and paragraph C) 
could be eliminated.  As far as Fork/EndFork, there was no intent to 
limit branching so these parameters can be nested.

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.
Again, this is one for our syntax experts.  We certainly want to be as 
consistent as possible.

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?
The re-connect can be accomplished at any pin or node.

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.
Without distributed ground and power planes, there is only one ground 
for a small board or uncoupled connector.  If you need a more detailed 
model, the board can be described in EDIF format and handled 
appropriately.  Also, without global interconnect models (ones with 
through paths for every contact and no dedicated ground lines) there is 
no practical way for any simulator to do ground bounce.  Again, please 
remember we are only dealing with first order uncoupled models at this 
time.  They are complicated enough.  Coupled models will be dealt with 
after we think we can do these so called 'simple ones'.

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?
I refer you to the last example under the [Reference Designator Map] 
keyword. It calls a resistor pack.  The .eid model of that resistor 
pack could be simply the network of resistors between external pins.

I hope these responses are helpful.  Again, thank you for your careful 
review of this interim BIRD 36c.

Hank