[ibis-interconn] Re: [EXT] [ibis-macro] BIRD draft 4 on relaxing the [Designator Pin List] requirement

  • From: "Muranyi, Arpad" <Arpad_Muranyi@xxxxxxxxxx>
  • To: "ibis-macro@xxxxxxxxxxxxx" <ibis-macro@xxxxxxxxxxxxx>, IBIS-Interconnect <ibis-interconn@xxxxxxxxxxxxx>
  • Date: Fri, 21 Jan 2022 21:24:03 +0000

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:

[cid:image002.png@01D80ED6.92558CE0]


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>
Sent: Friday, January 21, 2022 1:18 PM
To: Muranyi, Arpad <Arpad_Muranyi@xxxxxxxxxx>; ibis-macro@xxxxxxxxxxxxx; 
IBIS-Interconnect <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
=====================================================================

PNG image

Other related posts:

  1. Home
  2. ibis-interconn
  3. Archive
  4. 01-2022