Hello Everyone,
I thought I should write a summary to explain the reasons for why I didn’t
write a
BIRD draft for the addition of ‘NC’ to the [Designator Pin List] keyword yet.
This
might also help us in deciding whether in the relaxation BIRD we should prohibit
the unused pins to be present.
First, we will need to agree on what ‘NC’ actually means. I hear some of us
saying
that it means that there is no connection to that pin from the outside. Some
other
ones of us might think that it means that there is nothing behind a NC pin on
the
inside.
Is it outside or inside? For example, in the [Pin] keyword of the .ibs file,
does NC
mean that there is nothing behind that pin (i.e. there is no package and [Model]
on the inside) or does it mean that people shouldn’t connect anything to that
pin
when they put this part on a board or schematic, even though there may be
package
and [Model] on the inside of the .ibs file?
Same question in the EMD context. Does ‘NC’ in the [EMD Pin List] keyword mean
that there is no [EMD Model] connected inside the .emd file to that EMD pin (on
the inside), or does it mean that even though there may be an [EMD Model] on
the inside, people just shouldn’t put this EMD part on the board or schematics
and
connect anything to that EMD pin?
I tried to search in the IBIS spec for answers, but I didn’t find any so far.
Please
give me some page numbers if you find something that answers these questions.
Taking this a step further, What is “inside” / “outside” at the [Designator Pin
List]?
From the perspective of the EMD file, outside at the [Designator Pin List] would
mean “the other side of the fence”, i.e. inside the designator .ibs or .emd
file.
But from the designator .ibs or .emd file’s perspective, outside is inside the
EMD
file that instantiates them. So Einstein’s relativity theory is starting to
haunt us
here… 😊
But most importantly, the reason I thought of adding the signal_type NC to the
[Designator Pin List] keyword was because I (erroneously) thought that it would
eliminate the need for having to come up with a unique signal_name for all those
designator pins which are not used for anything. This turns out to be
incorrect,
because the ‘NC’ reserved word would go into the signal_type column, NOT the
signal_name column, and even if we had ‘NC’ in the signal_type column, the
model maker would still need to invent a unique signal_name for each of the
unused pins, even if they had ‘NC’ in the 3rd column. In short, having ‘NC’ in
[Designator Pin List] would not help with the problem I wanted to solve, i.e.
no having to invent unique signal_names for the 2nd column for unused designator
pins.
If that is the case, why bother adding ‘NC’ to [Designator Pin List]? Adding
it might
further complicate the question above, what does ‘NC’ really mean? Would it
mean that in this case, even if there is a matching signal_name between the
[EMD Pin List] and [Designator Pin List] keywords that they will NOT be
connected,
even in the presence of [EMD Model] between them? I don’t think so. This
would
require a whole new dissertation for these two keywords to explain how ‘NC’
would
work if that’s what it would do…
The only way I see the possibility to eliminate the requirement of having to
invent
unique signal_names for each unused designator pin is to prohibit unused
designator
pins from being listed under the [Designator Pin List].
In summary, I don’t see a reason to add ‘NC’ to the [Designator Pin List]
keyword,
and the only question I think we still need to answer is whether the unused pins
should be prohibited or allowed under the [Designator Pin List] keyword.
Thanks,
Arpad
======================================================================
