[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 07:13:12 +0000
Hello Everyone,
Attached is draft 6 for the [Designator Pin List] relaxation BIRD. I hope to
discuss this in the upcoming Interconnect meeting.
Thanks,
Arpad
===============================================================
From: ibis-interconn-bounce@xxxxxxxxxxxxx <ibis-interconn-bounce@xxxxxxxxxxxxx>
On Behalf Of Muranyi, Arpad
Sent: Wednesday, January 26, 2022 12:50 AM
To: ibis-macro@xxxxxxxxxxxxx; IBIS-Interconnect <ibis-interconn@xxxxxxxxxxxxx>
Subject: [ibis-interconn] Re: [EXT] [ibis-macro] BIRD draft 4 on relaxing the
[Designator Pin List] requirement
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<
mailto:rrwolff@xxxxxxxxxx>>
Sent: Friday, January 21, 2022 4:49 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,
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@01D81251.E1E14F00]
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
=======================================================================
Other related posts: