[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: Wed, 26 Jan 2022 06:49:37 +0000

Randy,

Thanks for your comments and suggestions.

 I would expect the presence of a NC pin in the .ibs file.
But in EMD we only care about the pin name (1st column) in the .ibs file’s [Pin]
keyword, and as a result we “don’t know” whether it is an NC pin or not in the
.ibs file…

Regarding my comments on “Terminator model” (and your agreeing with it), I
was wondering whether that sentence really refers to “Model_Type Terminator”
in a formal way, or whether it is talking in a lose sense about an {EMD Model]
which  is only connected to EMD pins (and no Designator pins), acting as a
termination on the module.  If that’s how it was meant, it should be OK, but it
sure could be interpreted as I read it when I commented on it…

As to the main topic of this discussion on how to relax the requirement of 
listing
all designator pins but allowing more than necessary, I am still thinking that 
the
best way of doing it would be to state that if the 3rd column is “NC” than the
line should be treated as if it wasn’t there, no matter what is in the 1st and 
2nd
columns.  That would allow “NC” in the 2nd column as well as a real signal name
that might be in use elsewhere without actually making any connections to them.

These would not be “pin type” I/O or rail, because either of those “pin types”
could be no connects at the a Designator interface (i.e. “NC”).

I will try to add something to my BIRD draft along those lines.

Thanks,

Arpad
====================================================================

From: Randy Wolff (rrwolff) <rrwolff@xxxxxxxxxx>
Sent: Friday, January 21, 2022 4:49 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,

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:

[cid:image001.png@01D8124C.E71A61F0]


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
=======================================================================

PNG image

Other related posts:

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