In emd.c, the [EMD Pin List] pin name, signal_name, and bus_label are all
checked against the reserved word list (GND", "NC",
"POWER","CIRCUITCALL","NA"), resulting in W6706. It’s a straightforward check,
not some strange quirk in the code. The same check is applied to [Begin EMD],
[EMD Parts], [EMD Designator List], [EMD Group], and [EMD Set], a total of 10
places in emd.c. The [Begin EMD] name can throw an error E1916 “Illegal use of
reserved word %s”, the rest are W6706 warnings “%s: Reserved word used for %s".
This looks like an error to me. Section 3.2 says NA is "used where data not
available”. That situation can be handled in some places, such as in
typ/min/max data. An example where NA actually is an error is where all three
dependent values of a typ/min/max line are NA. Obviously, scalar numeric values
such as Vinl = NA are a problem, but that throws E0149 "Invalid Vinl Value
("NA”)". So it’s hard to think of many places where the name of something
should be checked against the reserved word list, whether or not it’s good
practice to use that name.
Yet, the code checks for reserved words (all of them) in 60 places, throwing
E1916 in 25 places, possibly for most things that have a name. That is
something we probably should look into, and/or discuss whether things like
[Model] names can be NA (E0130).
Mike
On Jan 21, 2022, at 17:48, Randy Wolff ("rrwolff")
<dmarc-noreply@xxxxxxxxxxxxx> wrote:
Arpad,
Doing this:
E9 NA NA
F9 NA NC
Results in this from the parser:
WARNING (line 100) - NA: Reserved word used for signal_name
ERROR (line 100) - Invalid signal_type (NA)
WARNING (line 106) - NA: Reserved word used for signal_name
So, there is some special meaning to NA as a signal_name. Why, I don’t know.
Whatever we want to come up with as a definition for NC, in my mind it’s to
prevent having to do this:
[Designator Pin List] signal_name signal_type bus_label
U0.1 VDD POWER
U0.2 VSS GND
U0.3 VPP POWER VPP-B1
U0.4 VDDQ POWER
U0.5 NC_U0_5
U0.6 VSS GND
U0.7 NC_U0_7
U0.8 VDDQ POWER
U0.9 NC_U0_9
U0.10 VSS GND
U0.11 VSS GND
U0.12 NC_U0_12
U0.13 VDDQ POWER
U0.14 NC_U0_14
With changes we are making to [Designator Pin List], I can now leave out all
these pins completely, but I’d like the flexibility to still include them
all, and label them all as “NC”. Putting these contrived signal_names on
these pins just looks stupid to me.
As far as what’s connected to NC pins, well, what EDA tool simulates NC pins?
To me, NC indicates
don’t care
nothing to simulate
outside the scope of IBIS
Regarding this statement:
What would happen if the 2nd column
of the [Designator Pin List] has a signal name that matches that signal name
in the
[EMD Pin List] keyword, but has “NC” in its 3rd column? What would “NC” mean
in
this case?
I would expect the presence of a NC pin in the .ibs file.
Regarding this:
Other Notes: It is permitted to use a .ibs file or .emd file and a component
or module name to show the part pinout and to document some known rails and
digital I/O pins that are supported by the IBIS specification. Pins whose
functions are not supported by the IBIS specification could be documented as
“NC” pins or with Terminator models within these .ibs or .emd files.
I agree the word “some” is suspect. Removing that word reads more correctly
to me.
Including “or .emd” is not correct. Perhaps this is a vague reference to
nested EMDs that eventually point to a .ibs file, but as worded is incorrect.
I agree the Terminator models can only be in .ibs files. Additionally, the
mention of “NC” pins here implies connections to NC pins in referenced .ibs
files. Any net at the EMD level connecting to the “NC” pin of the designator
component could still be labeled as NC or given some other real name.
I’m sure there’s a way to get the lid back on this can of worms. 😊
Thanks,
Randy
From: ibis-interconn-bounce@xxxxxxxxxxxxx
<mailto:ibis-interconn-bounce@xxxxxxxxxxxxx>
<ibis-interconn-bounce@xxxxxxxxxxxxx
<mailto:ibis-interconn-bounce@xxxxxxxxxxxxx>> On Behalf Of Muranyi, Arpad
Sent: Friday, January 21, 2022 2:24 PM
To: ibis-macro@xxxxxxxxxxxxx <mailto:ibis-macro@xxxxxxxxxxxxx>;
IBIS-Interconnect <ibis-interconn@xxxxxxxxxxxxx
<mailto:ibis-interconn@xxxxxxxxxxxxx>>
Subject: [ibis-interconn] Re: [EXT] [ibis-macro] BIRD draft 4 on relaxing the
[Designator Pin List] requirement
CAUTION: EXTERNAL EMAIL. Do not click links or open attachments unless you
recognize the sender and were expecting this message.
Randy,
Thanks for your experiments and suggestions. Would you mind trying “NA” in
the
second column and see what happens, and perhaps in the first column too with
an
IBIS file that doesn’t have “NA” in the 1st column of its [Pin] keyword, and
perhaps
another IBIS file which does have one?
We have a definition for NA in Section 3.2:
<image001.png>
Note that is says NA can be used as pin and signal names, but what does “can
be used” mean?
Does it mean that if a signal name is “NA”, it means that “data not
available” or does it mean
that the name of the pin is “NA”? Same question for signal name… So I am
curious what the
parser will do if you put “NA” in those places in the EMD file you
experimented with.
Regarding your suggested text, I see your logic. A pin is not an I/O or rail
pin when the 3rd
column is “NC”, it is an “NC pin”. While this may work from a logical
(parser) perspective,
I wonder if it really makes sense. This raises the question of “what is an
NC pin”?
If we think in terms of the IBIS [Pin] keyword, or the [EMD Pin List]
keyword, I can see that
it might mean that nothing should be connected to that pin from the outside
(although we
could debate whether it has any other meanings). But even if we think in
these terms only,
what is the meaning of “NC pin” at the [Designator Pin List] interface? At
this interface we
do not have “EMD pins”, this interface is a connection point to designator
pins. So if we
say at this interface that we have an “NC pin”, are we saying that the “NC
pin” is the
pin of the designator that has been defined in the designator as “NC”? I
don’t think so,
for two reasons:
One, we only care about the pin name in the designator and ignore everything
else, which
implies that we don’t care whether the designator declares that pin as “NC”.
Second, what we are talking about is that we would allow the listing of
designator pins
even if there are no EMD models connecting to them. So this is clearly from
the perspective
of the EMD file. But EMD files don’t have “pins” at the designator interface…
Also, the [EMD Pin List] keyword doesn’t prohibit an internal connection to
an EMD
pin that has a valid signal name with “NC” in the 3rd column. So
theoretically we can
have an [EMD Model] connected to that pin. What would happen if the 2nd
column
of the [Designator Pin List] has a signal name that matches that signal name
in the
[EMD Pin List] keyword, but has “NC” in its 3rd column? What would “NC” mean
in
this case?
See what I am getting at?
Regarding the text you quoted from the spec, I have a few comments/questions:
Other Notes: It is permitted to use a .ibs file or .emd file and a component
or module name to show the part pinout and to document some known rails and
digital I/O pins that are supported by the IBIS specification. Pins whose
functions are not supported by the IBIS specification could be documented as
“NC” pins or with Terminator models within these .ibs or .emd files.
Why do we say “some” in the yellow highlight?
I understand that we can have Terminator models in .ibs files, but there is
no such
thing as Terminator model in EMD (or EBD). The 2nd cyan highlight could imply
that EMD has Terminator models…
Sorry to be so picky, but I think the real problem here is that we haven’t
defined
what we mean by “NC” well (or at all)…
Thanks,
Arpad
=======================================================================
From: Randy Wolff (rrwolff) <rrwolff@xxxxxxxxxx <mailto:rrwolff@xxxxxxxxxx>>
Sent: Friday, January 21, 2022 1:18 PM
To: Muranyi, Arpad <Arpad_Muranyi@xxxxxxxxxx
<mailto:Arpad_Muranyi@xxxxxxxxxx>>; ibis-macro@xxxxxxxxxxxxx
<mailto:ibis-macro@xxxxxxxxxxxxx>; IBIS-Interconnect
<ibis-interconn@xxxxxxxxxxxxx <mailto:ibis-interconn@xxxxxxxxxxxxx>>
Subject: RE: [EXT] [ibis-macro] BIRD draft 4 on relaxing the [Designator Pin
List] requirement
Arpad,
Here’s my analysis of NC as its usage currently exists for [EMD Pin List] as
well as what I’d like to see for [Designator Pin List].
Here’s the description (in blue) of NC from [EMD Pin List]. Note the same
text is found in this section as [Designator Pin List] describing only two
columns allowed for I/O pins.
I/O pins shall consist of exactly two columns containing the pin_name and
signal_name entries. No signal_type or bus_label entry is permitted for I/O
pins.
The third column (signal_type) is required for rail pins and no-connect pins.
The allowed values for this third column (as defined in Section 3.2, “SYNTAX
RULES”) are:
POWER - reserved model name, used with power supply pins
GND - reserved model name, used with ground pins
NC - reserved model name, used with no-connect pins
“NC” is a legal signal_type and indicates that the pin is a “no-connect”. As
described in Section 3.2, “SYNTAX RULES” the reserved words “GND”, “POWER”,
and “NC” are case-insensitive.
I checked out the parser behavior related to this on an EMD example I have of
a stacked die package. I have two pins that I use the “NC” signal_type for
as follows in [EMD Pin List]:
E9 UZQ NC
F9 LZQ NC
No messages from the parser related to this syntax. But what if those pins
were labeled “NC” in the datasheet for the package? Changing [EMD Pin List]
to:
E9 NC NC
F9 NC NC
Results in two warnings from the parser:
WARNING (line 100) - NC: Reserved word used for signal_name
WARNING (line 106) - NC: Reserved word used for signal_name
Was this really the intended behavior of using NC in the [EMD Pin List]? I’d
argue that we intended to allow NC as a signal_name, where it is ignored as
being an “I/O” and treated as having “NC” functionality., meaning it isn’t
connected to anything, so no connection to other “NC” pins is implied through
matching signal_name connectivity. We might need to add a statement to [EMD
Pin List] to clarify this intention.
I’d argue that if you give a pin in [EMD Pin List] a unique signal_name such
as “UZQ”, that’s implying there really could be something connected there
(treated like an I/O pin), but it’s not modeled by IBIS. We even make a
statement about this in [EMD Parts]:
Other Notes: It is permitted to use a .ibs file or .emd file and a component
or module name to show the part pinout and to document some known rails and
digital I/O pins that are supported by the IBIS specification. Pins whose
functions are not supported by the IBIS specification could be documented as
“NC” pins or with Terminator models within these .ibs or .emd files.
Now on to [Designator Pin List]. Here’s the description (in blue) from
[Designator Pin List]:
I/O pin entries shall consist of exactly two columns containing the pin_name
and signal_name entries. No signal_type or bus_label entry is permitted for
I/O pins. The signal_name entry may also be used to signify the primary
connection to other I/O pins (necessary for Aggressor_Only described later).
The third column (signal_type) is required for rail pins. The allowed values
for this third column (as defined in Section 3.2, “SYNTAX RULES”) are:
POWER - reserved model name, used with power supply pins
GND - reserved model name, used with ground pins
As described in Section 3.2, “SYNTAX RULES” the reserved words “GND” and
“POWER” are case-insensitive.
I think simple changes to mirror [EMD Pin List] (highlighted below in yellow)
easily add NC:
I/O pin entries shall consist of exactly two columns containing the pin_name
and signal_name entries. No signal_type or bus_label entry is permitted for
I/O pins. The signal_name entry may also be used to signify the primary
connection to other I/O pins (necessary for Aggressor_Only described later).
The third column (signal_type) is required for rail pins and no-connect pins.
The allowed values for this third column (as defined in Section 3.2, “SYNTAX
RULES”) are:
POWER - reserved model name, used with power supply pins
GND - reserved model name, used with ground pins
NC - reserved model name, used with no-connect pins
“NC” is a legal signal_type and indicates that the pin is a “no-connect”. As
described in Section 3.2, “SYNTAX RULES” the reserved words “GND”, “POWER”,
and “NC” are case-insensitive.
Additionally, whatever we do to [EMD Pin List] to clarify “NC” as a
signal_name should be done to [Designator Pin List].
Thanks,
Randy
From: ibis-interconn-bounce@xxxxxxxxxxxxx
<mailto:ibis-interconn-bounce@xxxxxxxxxxxxx>
<ibis-interconn-bounce@xxxxxxxxxxxxx
<mailto:ibis-interconn-bounce@xxxxxxxxxxxxx>> On Behalf Of Muranyi, Arpad
Sent: Friday, January 21, 2022 10:14 AM
To: ibis-macro@xxxxxxxxxxxxx <mailto:ibis-macro@xxxxxxxxxxxxx>;
IBIS-Interconnect <ibis-interconn@xxxxxxxxxxxxx
<mailto:ibis-interconn@xxxxxxxxxxxxx>>
Subject: [ibis-interconn] Re: [EXT] [ibis-macro] BIRD draft 4 on relaxing the
[Designator Pin List] requirement
CAUTION: EXTERNAL EMAIL. Do not click links or open attachments unless you
recognize the sender and were expecting this message.
Randy, (and Everyone),
Thanks for the suggestion, I like it, so I made a draft 5 with your text
instead of mine (attached).
We still need to figure out how to go about “NC”, though. Any suggestions,
anyone?
Remember, the issue I stumbled on is that currently the spec says that for
I/O pins only two
columns are allowed, while the “NC” reserved word would go into the 3rd
column if we allowed
it… Should we allow three columns for I/O pins if (and only if) the 3rd
column contains “NC”?
Thanks,
Arpad
===============================================================================
From: Randy Wolff (rrwolff) <rrwolff@xxxxxxxxxx <mailto:rrwolff@xxxxxxxxxx>>
Sent: Wednesday, January 19, 2022 5:31 PM
To: Muranyi, Arpad <Arpad_Muranyi@xxxxxxxxxx
<mailto:Arpad_Muranyi@xxxxxxxxxx>>; ibis-macro@xxxxxxxxxxxxx
<mailto:ibis-macro@xxxxxxxxxxxxx>; IBIS-Interconnect
<ibis-interconn@xxxxxxxxxxxxx <mailto:ibis-interconn@xxxxxxxxxxxxx>>
Subject: RE: [EXT] [ibis-macro] BIRD draft 4 on relaxing the [Designator Pin
List] requirement
Hi Arpad,
Here is my attempt at shortening the [Designator Pin List] text from your
BIRD draft. I’m not sure the pin_name, signal_name, and bus_label mentions
are necessary, and I used less formal versions of the keywords, as is common
in these types of descriptions.
Your Draft 4 text:
“The keyword and the list of its subparameters shall be followed by at least
as many rows of information as needed to provide a matching designator
pin_name, signal_name or bus_label entry for each terminal line
Qualifier_entry that references a designator pin_name, signal_name or
bus_label of all [EMD Model] keywords which are contained by all those [EMD
Set] keywords which are referenced by all those [EMD Group] keyword which are
enclosed by the [Begin EMD] / [End EMD] keywords in which the [Designator Pin
List] keyword is located. Designator pin names which are not referenced by
any terminal line Qualifier_entries in any of the [EMD Model]s may optionally
be listed under the [Designator Pin List] keyword.”
My text:
“The keyword and the list of its subparameters shall be followed by rows of
information containing all designator pins referenced by terminal lines found
in all the EMD Models contained by EMD Sets and referenced by all EMD Groups
found in the .emd file. Designator pin names which are not referenced by any
terminal line Qualifier_entry in any of the EMD Models may optionally be
listed under the [Designator Pin List] keyword.”
Thanks,
Randy
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: Tuesday, January 18, 2022 12:57 PM
To: ibis-macro@xxxxxxxxxxxxx <mailto:ibis-macro@xxxxxxxxxxxxx>;
IBIS-Interconnect <ibis-interconn@xxxxxxxxxxxxx
<mailto:ibis-interconn@xxxxxxxxxxxxx>>
Subject: [EXT] [ibis-macro] BIRD draft 4 on relaxing the [Designator Pin
List] requirement
CAUTION: EXTERNAL EMAIL. Do not click links or open attachments unless you
recognize the sender and were expecting this message.
Hello Everyone,
Attached is draft 4 of the BIRD that I wrote for relaxing the requirement of
having to include all designator pin names in the [Designator Pin List]
keyword.
The color coding is as follows: original BIRD draft text – no color. draft
2 = yellow,
draft 3 = green, draft 4 = cyan. The reason I made the changes in cyan is
because
the corresponding words were not correct in the previous draft. (Thanks for
Curtis to point that out). The sentence is still long and complicated, so I
am open
to suggestions on how to make it easier to read.
Note that I still didn’t add the text for making ‘NC’ available, since I am
waiting
for some discussions on that topic to answer some of my questions that I
raised
in a previous email.
I hope we can discuss this in the Interconnect meeting tomorrow.
Thanks,
Arpad
=====================================================================
