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

From: "Bob Ross" <bob@xxxxxxxxxxxxxxxxx>
To: "'IBIS-Interconnect'" <ibis-interconn@xxxxxxxxxxxxx>, <ibis-macro@xxxxxxxxxxxxx>
Date: Tue, 1 Mar 2022 15:51:41 -0800

Arpad,

Thanks for the clarification.

It looks like you are correct, and the proposed rule is already covered.

Sorry about my confused rule due to on-the=fly editing.

I think that the file can be checked so that no signal_name associated with a
POWER or GND pin_name would be used as a signal_name for an NC pin.

The same could apply for Pin_I/O terminals, but the syntax requires Pin_I/0
pin_name <name>.  This syntax would  be illegal for NC pin_names because the
syntax works only for terminals without any signal_type column entry.  So an NC
pin with a the duplicate signal_name would not be permitted for I/O paths.

Bob

From: ibis-interconn-bounce@xxxxxxxxxxxxx
[mailto:ibis-interconn-bounce@xxxxxxxxxxxxx] On Behalf Of Muranyi, Arpad
Sent: Monday, February 28, 2022 11:12 AM
To: 'IBIS-Interconnect'; ibis-macro@xxxxxxxxxxxxx
Subject: [ibis-interconn] Re: BIRD draft 9 on relaxing the [Designator Pin
List] requirement

Bob,

Thanks for your comments.  To be honest, I don’t quite understand the rule you

suggest, it seems that it has a few typos which confuse me…  It would be nice if

you could rewrite what you are trying to propose…

However, I think this situation wouldn’t be allowed according to what we have

in the v7.1 spec.  (pg. 364):

and a corresponding rule on pg. 368:

I think these rules would prohibit your counter example.  Or am I missing
something?

Thanks,

Arpad

=======================================================================

From: ibis-interconn-bounce@xxxxxxxxxxxxx <ibis-interconn-bounce@xxxxxxxxxxxxx>
On Behalf Of Bob Ross
Sent: Wednesday, February 23, 2022 1:40 PM
To: 'IBIS-Interconnect' <ibis-interconn@xxxxxxxxxxxxx>; ibis-macro@xxxxxxxxxxxxx
Cc: bob@xxxxxxxxxxxxxxxxx
Subject: [ibis-interconn] Re: BIRD draft 9 on relaxing the [Designator Pin
List] requirement

All,

Per the AR, a new rule is needed for [EMD Model]:

No signal_name for any NC signal_type terminal shall be distinct from to any
signal_name used for I/O, POWER, or GND signal_type pins.

Counter Example (without the rule):

[Designator Pin List]

U1.1    VDD   NC

U1.2    VDD   NC

U2.1    VDD   NC

U2.2    VDD   NC

U1.3    VDD   POWER

U1.3    VDD   POWER

End Designator Pin List]

[EMD Model]

…

1   Pin_Rail   signal_name  VDD  | from [EMD Pin List], could include an NC pin.

| This is ambiguous –signal_type pins with “VDD” and for  “NC” overlap with
POWER pins with signal_name “VDD?

2   Pin_Rail  signal_name   U1.VDD

3   Pin_Rail  signal_name   U2.VDD

…

[End EMD  Model]

Bob

From: ibis-interconn-bounce@xxxxxxxxxxxxx
[mailto:ibis-interconn-bounce@xxxxxxxxxxxxx] On Behalf Of Muranyi, Arpad
Sent: Wednesday, February 23, 2022 10:46 AM
To: IBIS-Interconnect; ibis-macro@xxxxxxxxxxxxx
Subject: [ibis-interconn] BIRD draft 9 on relaxing the [Designator Pin List]
requirement

Hello Everyone,

Attached is draft 9 of the [Designator Pin List] relaxation BIRD which

includes the changes we made in the Interconnect teleconference this

morning.

Note that I added a comment to the beginning of the last sentence:

“The purpose of this  is to allow the model maker to document designator pins
even if no connections are made to them from any EMD Model.”

because with the changes we made before this sentence the word “this”

becomes ambiguous.  What is “this” referring to?  (I know the answer),

but I am not sure how to change this sentence to make that clear to the

reader.

Let me know if you have any questions/comments/suggestions…

Related to this, I had an AR to look at the terminal line definition under the

[EMD Model] keyword and see if “NC” is mentioned or should be mentioned

there.  If I am not missing anything, currently there is no mention of “NC”
there.

On pg. 380, I only see this much:

On pg. 381 we refer to “I/O connections” and “rail connections” (but no

“NC connections”) and talk about “EMD Pins” and “Designator Pins” but

no “NC Pins”.  Considering that our interpretation of NC in the EMD pin

list was something like “nothing connected to this pin from the outside”,

and considering that in the current spec we don’t have NC on Designator

pins, this seems to be correct.

However, considering that pg. 364 does talk about “no-connect pins”

almost as a pin type (similar to “power supply pins” and “ground pins”)

I conclude that we should really have a Terminal_type Pin_NC in addition to

the currently defined Terminal_types Pin_I/O, Pin_Rail and A_gnd, and

consequently pg. 381 should also list the rules for “Pin_NC connections”

as well  😊:

As you can tell, I might be a little sarcastic here, but this is yet another

manifestation of the lack of defining what ”NC” really means…

Now, more seriously, what we might need to do is add verbiage to many

of the bullets on pg. 381 to mention the situation with NC on Designator

Pins, and perhaps on EMD Pins also (since NC might mean totally different

things in those two situations)…

Thanks,

Arpad

===========================================================

From: ibis-macro-bounce@xxxxxxxxxxxxx <ibis-macro-bounce@xxxxxxxxxxxxx> On
Behalf Of Muranyi, Arpad
Sent: Wednesday, February 2, 2022 10:45 AM
To: ibis-macro@xxxxxxxxxxxxx; IBIS-Interconnect <ibis-interconn@xxxxxxxxxxxxx>
Subject: [ibis-macro] BIRD draft 7 on relaxing the [Designator Pin List]
requirement

Hello Everyone,

Attached is draft 7 for the [Designator Pin List] relaxation BIRD.  This version

is almost identical to draft 6 with only a small grammatical change in one of

the sentences.  Questions, comments are welcome.

Thanks,

Arpad

===============================================================

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

Other related posts: