[ibis-interconn] Re: NC or not to NC...
- From: "Muranyi, Arpad" <Arpad_Muranyi@xxxxxxxxxx>
- To: "ibis-macro@xxxxxxxxxxxxx" <ibis-macro@xxxxxxxxxxxxx>, IBIS-Interconnect <ibis-interconn@xxxxxxxxxxxxx>
- Date: Thu, 13 Jan 2022 03:00:10 +0000
Bob,
Thanks for your comments. Looks like the three of us (you, Walter, and me)
agree that going with the ‘NA” idea in the 2nd column is not a good idea. But
I think if we add ‘NC’ back as a reserved word for the 3rd column, we should
still add the rule for it that if it is present in the 3rd column (for
signal_type),
the signal_name in the 2nd column should be ignored/ineffective/meaningless
as far as connectivity is concerned. I understand your point that in this case
there will be most likely no [EMD Model] terminal lines referencing these
designator pins, but I want to make it absolutely sure that there would be
no chance of EDA tools to inadvertently doing something that the model maker
didn’t intend to do… And I also want to make sure that the model maker wouldn’t
feel obligated to come up with unique signal_names, being afraid of possible
connections made by the EDA tool. But we can discuss this further…
Thanks,
Arpad
===================================================================
From: Bob Ross <bob@xxxxxxxxxxxxxxxxx>
Sent: Wednesday, January 12, 2022 6:04 PM
To: wkatz@xxxxxxxxxxxxx; Muranyi, Arpad <Arpad_Muranyi@xxxxxxxxxx>;
ibis-macro@xxxxxxxxxxxxx
Subject: RE: [ibis-macro] Re: NC or not to NC...
Arpad,
I would vote No for the “NA” usage (already a reserved word) and the proposed
restrictive rule. We would already have the equivalent restriction.
There is no requirement that all [EMD Pin List} and any [Designator Pin List]
pins are connected in any [EMD Model].
So if the intention is to not connect an NC pin, then its electrical connection
will not be documented.
The EMD board designer might have had a valid reason (reserved for future
expansion) for adding additional routing to NC pins. Such “connections’ can be
designated by unique signal_names (NC1, NC2, …)
So the “NA” functionality already exists if we support NC in [Designator Pin
List].
Bob
From: ibis-macro-bounce@xxxxxxxxxxxxx<mailto:ibis-macro-bounce@xxxxxxxxxxxxx>
[mailto:ibis-macro-bounce@xxxxxxxxxxxxx] On Behalf Of Walter Katz
Sent: Wednesday, January 12, 2022 11:52 AM
To: Arpad_Muranyi@xxxxxxxxxx<mailto:Arpad_Muranyi@xxxxxxxxxx>;
ibis-macro@xxxxxxxxxxxxx<mailto:ibis-macro@xxxxxxxxxxxxx>
Subject: [ibis-macro] Re: NC or not to NC...
Yes
Walter Katz
Work 508.647-7633
Cell 720.417-3762
[Description: Description: Visit MathWorks.com]
From: ibis-macro-bounce@xxxxxxxxxxxxx<mailto:ibis-macro-bounce@xxxxxxxxxxxxx>
<ibis-macro-bounce@xxxxxxxxxxxxx<mailto:ibis-macro-bounce@xxxxxxxxxxxxx>> On
Behalf Of Muranyi, Arpad
Sent: Wednesday, January 12, 2022 1:22 PM
To: ibis-macro@xxxxxxxxxxxxx<mailto:ibis-macro@xxxxxxxxxxxxx>
Subject: [ibis-macro] Re: NC or not to NC...
Walter, (and Everyone),
Another option, instead of adding a reserved signal name ‘NA’ for the 2nd column
would be to write a rule that would state that if the 3rd column has ‘NC’, then
the
2nd column becomes meaningless, i.e. the usual associations between signal names
in [EMD Pin List] and [Designator Pin List] would not be made when the 3rd
column
has ‘NC’.
Would that be a better way to do this?
Thanks,
Arpad
=====================================================================
From: ibis-macro-bounce@xxxxxxxxxxxxx<mailto:ibis-macro-bounce@xxxxxxxxxxxxx>
<ibis-macro-bounce@xxxxxxxxxxxxx<mailto:ibis-macro-bounce@xxxxxxxxxxxxx>> On
Behalf Of Muranyi, Arpad
Sent: Monday, January 10, 2022 12:27 PM
To: ibis-macro@xxxxxxxxxxxxx<mailto:ibis-macro@xxxxxxxxxxxxx>
Subject: [ibis-macro] Re: NC or not to NC...
Walter
That makes more sense, but then we would also need to make ‘NA’ an
official reserved signal_name (which it is not at the moment), in addition
to make ‘NC’ a reserved signal_type under [Designator Pin List].
So, are you suggesting to go with this ‘NA’ ‘NC’ approach and allow (but
not require) unused designator pins to be listed in the [Designator Pin
List] keyword, if so desired?
Thanks,
Arpad
=============================================================
From: Walter Katz <wkatz@xxxxxxxxxxxxx<mailto:wkatz@xxxxxxxxxxxxx>>
Sent: Monday, January 10, 2022 12:16 PM
To: Muranyi, Arpad <Arpad_Muranyi@xxxxxxxxxx<mailto:Arpad_Muranyi@xxxxxxxxxx>>;
ibis-macro@xxxxxxxxxxxxx<mailto:ibis-macro@xxxxxxxxxxxxx>
Subject: RE: NC or not to NC...
Arpad,
You are correct. What I meant was to use NC for signal_type (Not Connected) and
NA for signal_name on NC signal_type.
Therefore EMD and Designator pins that are “NA and NC” should not appear in any
[EMD Model]
Walter
Walter Katz
Work 508.647-7633
Cell 720.417-3762
[Description: Description: Visit MathWorks.com]
From: ibis-macro-bounce@xxxxxxxxxxxxx<mailto:ibis-macro-bounce@xxxxxxxxxxxxx>
<ibis-macro-bounce@xxxxxxxxxxxxx<mailto:ibis-macro-bounce@xxxxxxxxxxxxx>> On
Behalf Of Muranyi, Arpad
Sent: Sunday, January 9, 2022 11:33 PM
To: ibis-macro@xxxxxxxxxxxxx<mailto:ibis-macro@xxxxxxxxxxxxx>
Subject: [ibis-macro] Re: NC or not to NC...
Walter,
Thanks for your reply. To be honest, I am quite surprised by a few things you
wrote (aside from
the “typos”)… By “typo”, I am referring to “[Interconnect Model]”. I assume
you meant “[EMD
Model]” instead…
Regarding your fist sentence:
Please be careful. ‘NC’ is only a reserved name in the 3rd column which isAll EMD Pins and all Designator Pins that have the same signal name (and
not “NC”) are “connected”
signal_type (NOT signal_name),
and it is only available in [EMD Pin List] (and NOT in [Designator Pin List]).
So as far as I understand, it
would be legal to use ‘NC’ as a signal_name in the 2nd column in both [EMD Pin
List] and [Designator Pin List]
to indicate a “modeled connection”. (Stupid, but legal, as far as I can tell).
Good question. I think the answer is on pg. 392:What should the EDA tool do for the interconnect model that connects pins
that have the same
signal name, but there is no [Interconnect Model] containing terminals of
these pins?
[cid:image002.png@01D807F7.484D4650]
To me this means that if there are no [EMD Model]s in an EMD file with terminal
lines
that which reference the both the EMD pin and the designator pin, then those
pins will
be disconnected even if they have the same signal_name. I don’t remember
anything
in the spec that says that these pins would be shorted. I only remember pin
shorting
mentioned when multiple pins on the same interface have the same signal_name or
bus_label name, but this is only allowed for rail pins (not I/O). But even in
this case, as
far as I understand, the shorting is only happening between pins on the same
interface,
and not between interfaces. In other words, the signal_name “VDD” on a bunch
of EMD
pins will short those EMD pins when a terminal line of an [EMD Model] uses
signal_name
“VDD”, and similarly, if there are a bunch of pins in the [Designator Pin List]
with
signal_name “VDD”, these pins will also be shorted if a terminal line in the
[EMD Model]
uses “U1.VDD” (or *.VDD). But, as far as I can tell, if there are no such
terminal lines in
any of the [EMD Model]s, or only one or the other terminal line exists, the EMD
VDD
pins and designator VDD pins would not be shorted together.
I don’t understand the rest of your email. What is “An IBIS Terminal pin”?
How can you have
“IBIS … pins” in the [EMD Pin List] keyword? Regarding the antenna model, I
don’t see how it
is related to the ‘NC’ discussion… The “chip side” (Tx or Rx) of the antenna
would most likely
go to a designator pin (to be connected to the buffer model on the die). There
would be no
pin on the [EMD Pin List] side, because the antenna doesn’t go to any EMD pins,
it just radiates
to the world from the antenna trace of the module (or picks up the signal from
ether on that
antenna trace on the module). I don’t see how ‘NC’ gets involved in this case.
Anyway, we can probably discuss this better in the meeting verbally. I just
wanted to get
people’s minds ticking so we can have a more meaningful discussion…
Thanks,
Arpad
===============================================================================
From: Walter Katz <wkatz@xxxxxxxxxxxxx<mailto:wkatz@xxxxxxxxxxxxx>>
Sent: Sunday, January 9, 2022 8:12 PM
To: Muranyi, Arpad <Arpad_Muranyi@xxxxxxxxxx<mailto:Arpad_Muranyi@xxxxxxxxxx>>;
ibis-macro@xxxxxxxxxxxxx<mailto:ibis-macro@xxxxxxxxxxxxx>
Subject: RE: NC or not to NC...
Arpad,
All EMD Pins and all Designator Pins that have the same signal name (and not
“NC”) are “connected”. The .emd file may or may not have an [Interconnect
Model] with those pins in it.
What should the EDA tool do for the interconnect model that connects pins that
have the same signal name, but there is no [Interconnect Model] containing
terminals of these pins?
The first answer is that the model maker though that there would be no demand
to simulate this signal name, or that the model didn’t mater and the pins could
be shorted together.
The question you rose is different. If a pin is “NC”, then it is not connected
to any other pin, therefore what is behind the pin does not matter. It could be
one of the following:
1. Designator Pin
* An IBIS NC pin
* An IBIS I/O pin
* An IBIS Terminal pin
* An EMD pin
2. EMD Pin
* An IBIS NC pin
* An IBIS I/O pin
* An IBIS Terminal pin
* None of the above
In each of these cases the pin is not connected to any other pin in the module.
In general, IBIS supports simulation between I/O pins. I guess it could have
been an Antennae routed in the Module. Even for this case the model maker
should give it a unique name, and create an “Antennae Interconnect Model” with
just one terminal. So NC could be Not Connected, or Do Not Care.
What is Inside a Designator Pin and outside a EMD Pin does not matter, they are
both outside the EMD interconnect.
As an EDA tool developer, I just ignore the NC pins when generating
connectivity, it is as if these pins did not exist.
Walter
Walter Katz
Work 508.647-7633
Cell 720.417-3762
[Description: Description: Visit MathWorks.com]
From: ibis-macro-bounce@xxxxxxxxxxxxx<mailto:ibis-macro-bounce@xxxxxxxxxxxxx>
<ibis-macro-bounce@xxxxxxxxxxxxx<mailto:ibis-macro-bounce@xxxxxxxxxxxxx>> On
Behalf Of Muranyi, Arpad
Sent: Sunday, January 9, 2022 8:29 PM
To: ibis-macro@xxxxxxxxxxxxx<mailto:ibis-macro@xxxxxxxxxxxxx>
Subject: [ibis-macro] NC or not to NC...
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
======================================================================
- Follow-Ups:
- [ibis-interconn] Re: NC or not to NC...
- From: Muranyi, Arpad
- [ibis-interconn] Re: NC or not to NC...
Other related posts:
- » [ibis-interconn] Re: NC or not to NC... - Muranyi, Arpad
- » [ibis-interconn] Re: NC or not to NC...- Muranyi, Arpad
