[ibis-macro] Re: [ibis-interconn] Re: Proposed changes on reference connections for BIRD189

  • From: Walter Katz <wkatz@xxxxxxxxxx>
  • To: "IBIS-Interconnect" <ibis-interconn@xxxxxxxxxxxxx>, <ibis-macro@xxxxxxxxxxxxx>
  • Date: Wed, 29 Nov 2017 12:46:43 -0500 (EST)

The simplest thing to do at this point is to put the rule in BIRD 189. 

 

Walter

 

Walter Katz

wkatz@xxxxxxxxxx <mailto:wkatz@xxxxxxxxxx> 

978.461-0449 x 133

Mobile 303.335-6156

 

From: ibis-interconn-bounce@xxxxxxxxxxxxx
[mailto:ibis-interconn-bounce@xxxxxxxxxxxxx] On Behalf Of Muranyi, Arpad
Sent: Wednesday, November 29, 2017 12:39 PM
To: IBIS-Interconnect <ibis-interconn@xxxxxxxxxxxxx>;
ibis-macro@xxxxxxxxxxxxx
Subject: [ibis-interconn] Re: Proposed changes on reference connections
for BIRD189

 

Walter,

 

Just remember Murphy's law:  If it can be done, it will be done.

 

Either out of plain stupidity or inexperience, etc.  I have done it myself

for the former reason.   :)  And I got reminded to my stupid mistake by

my simulator in no time.

 

So I would still prefer the rule in BIRD189.  Do you have a preference?

 

Thanks,

 

Arpad

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

 

From: ibis-interconn-bounce@xxxxxxxxxxxxx
<mailto:ibis-interconn-bounce@xxxxxxxxxxxxx>
[mailto:ibis-interconn-bounce@xxxxxxxxxxxxx] On Behalf Of Walter Katz
Sent: Wednesday, November 29, 2017 11:34 AM
To: IBIS-Interconnect <ibis-interconn@xxxxxxxxxxxxx
<mailto:ibis-interconn@xxxxxxxxxxxxx> >; ibis-macro@xxxxxxxxxxxxx
<mailto:ibis-macro@xxxxxxxxxxxxx> 
Subject: [ibis-interconn] Re: Proposed changes on reference connections
for BIRD189

 

Arpad,

 

And I think the one thing that will absolutely work: What model maker in
their right mind would create a .subckt with "0" on one of the terminals.
I am not sure they will defend such a model whether they used it in BIRD
189, or supplied that package model to their customers.

 

Walter

 

Walter Katz

wkatz@xxxxxxxxxx <mailto:wkatz@xxxxxxxxxx> 

978.461-0449 x 133

Mobile 303.335-6156

 

From: ibis-interconn-bounce@xxxxxxxxxxxxx
<mailto:ibis-interconn-bounce@xxxxxxxxxxxxx>
[mailto:ibis-interconn-bounce@xxxxxxxxxxxxx] On Behalf Of Muranyi, Arpad
Sent: Wednesday, November 29, 2017 12:28 PM
To: IBIS-Interconnect <ibis-interconn@xxxxxxxxxxxxx
<mailto:ibis-interconn@xxxxxxxxxxxxx> >; ibis-macro@xxxxxxxxxxxxx
<mailto:ibis-macro@xxxxxxxxxxxxx> 
Subject: [ibis-interconn] Re: Proposed changes on reference connections
for BIRD189

 

Walter,

 

I agree this should be an easy "Finch", but I don't follow what you say
about getting

it through the Open Forum before BIRD189 gets to a final vote.  IBIS-ISS
is a separate

specification.  If we make a change to it, we will have to release a new
version for it.

Do you expect that to be done before BIRD189 is voted on?  (I don't think
it would

go that fast.).  The best I would expect that it might get released
simultaneously

with IBIS v7.0.

 

Now, if that were to happen, we wouldn't need to add the rule we discussed
today

in BIRD189, because the IBIS-ISS specification itself would take care of
it.  We would

just have to make sure that people would never use IBIS-ISS v1.0 models
with BIRD189

models.

 

On the other hand, if we have this rule in BIRD189, it would not prohibit
node0 on

the .subckt definition lines for IBIS-ISS in general, but it would
prohibit making such

subcircuits for BIRD189 purposes.  And that would be in effect regardless
of the IBIS-ISS

version.

 

I think having this rule in BIRD189 might be the simpler way to go about
this, because it

would be independent of the IBIS-ISS specification.

 

What do you think would be the better approach?

 

Thanks,

 

Arpad

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

 

 

From: ibis-interconn-bounce@xxxxxxxxxxxxx
<mailto:ibis-interconn-bounce@xxxxxxxxxxxxx>
[mailto:ibis-interconn-bounce@xxxxxxxxxxxxx] On Behalf Of Walter Katz
Sent: Wednesday, November 29, 2017 11:15 AM
To: IBIS-Interconnect <ibis-interconn@xxxxxxxxxxxxx
<mailto:ibis-interconn@xxxxxxxxxxxxx> >; ibis-macro@xxxxxxxxxxxxx
<mailto:ibis-macro@xxxxxxxxxxxxx> 
Subject: [ibis-interconn] Re: Proposed changes on reference connections
for BIRD189

 

Arpad,

 

Yes, I think we came to the same conclusion in the IBIS_Intereconnect
meeting.

 

I think we should communicate with the EDA vendors that have there own
SPICE simulators if they are OK with or Very Much want this rule added to
IBIS-ISS. This should be an easy "Finch" to write for IBIS-ISS and get
through the Open Forum before 189 gets to a final vote.

 

Walter

 



 

Walter

 

Walter Katz

wkatz@xxxxxxxxxx <mailto:wkatz@xxxxxxxxxx> 

978.461-0449 x 133

Mobile 303.335-6156

 

From: ibis-interconn-bounce@xxxxxxxxxxxxx
<mailto:ibis-interconn-bounce@xxxxxxxxxxxxx>
[mailto:ibis-interconn-bounce@xxxxxxxxxxxxx] On Behalf Of Muranyi, Arpad
Sent: Wednesday, November 29, 2017 12:06 PM
To: IBIS-Interconnect <ibis-interconn@xxxxxxxxxxxxx
<mailto:ibis-interconn@xxxxxxxxxxxxx> >; ibis-macro@xxxxxxxxxxxxx
<mailto:ibis-macro@xxxxxxxxxxxxx> 
Subject: [ibis-interconn] Re: Proposed changes on reference connections
for BIRD189

 

Walter,

 

What we don't want to allow is the node "0" (and its synonyms) on the
.subckt line:

 

.subckt test 1 0

R1 1 0 50

.ends

 

The issue is not how subcircuits are called, it is how they are defined.

 

Thanks,

 

Arpad

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

 

From: ibis-interconn-bounce@xxxxxxxxxxxxx
<mailto:ibis-interconn-bounce@xxxxxxxxxxxxx>
[mailto:ibis-interconn-bounce@xxxxxxxxxxxxx] On Behalf Of Walter Katz
Sent: Wednesday, November 29, 2017 10:21 AM
To: IBIS-Interconnect <ibis-interconn@xxxxxxxxxxxxx
<mailto:ibis-interconn@xxxxxxxxxxxxx> >; ibis-macro@xxxxxxxxxxxxx
<mailto:ibis-macro@xxxxxxxxxxxxx> 
Subject: [ibis-interconn] Re: Proposed changes on reference connections
for BIRD189

 

Arpad,

 

"Since HSPICE itself issues a message and recommends not to do this,
shouldn't we mention that in IBIS-ISS and discourage people from doing
it?"

 

Is not the issue how IBIS-ISS subckts are called, what exactly inside the
IBIS-ISS model be discouraged?

 

Walter

 

Walter Katz

wkatz@xxxxxxxxxx <mailto:wkatz@xxxxxxxxxx> 

978.461-0449 x 133

Mobile 303.335-6156

 

From: ibis-interconn-bounce@xxxxxxxxxxxxx
<mailto:ibis-interconn-bounce@xxxxxxxxxxxxx>
[mailto:ibis-interconn-bounce@xxxxxxxxxxxxx] On Behalf Of Muranyi, Arpad
Sent: Wednesday, November 29, 2017 11:18 AM
To: IBIS-Interconnect <ibis-interconn@xxxxxxxxxxxxx
<mailto:ibis-interconn@xxxxxxxxxxxxx> >; ibis-macro@xxxxxxxxxxxxx
<mailto:ibis-macro@xxxxxxxxxxxxx> 
Subject: [ibis-interconn] Re: Proposed changes on reference connections
for BIRD189

 

Some simulators specifically prohibit it.  While the expectation is that
non-HSPICE

simulators will implement whatever IBIS-ISS says (and allows), imagine a
simulator

who can do pretty much everything that is in IBIS-ISS, but would error out
on this

situation, and it would take a huge effort for them to implement HSPICE
compatibility

on this case.  Should these simulators be excluded from being able to
simulate these

models?

 

Since HSPICE itself issues a message and recommends not to do this,
shouldn't we

mention that in IBIS-ISS and discourage people from doing it?

 

Thanks,

 

Arpad

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

 

From: ibis-macro-bounce@xxxxxxxxxxxxx
<mailto:ibis-macro-bounce@xxxxxxxxxxxxx>
[mailto:ibis-macro-bounce@xxxxxxxxxxxxx] On Behalf Of Walter Katz
Sent: Wednesday, November 29, 2017 10:02 AM
To: IBIS-Interconnect <ibis-interconn@xxxxxxxxxxxxx
<mailto:ibis-interconn@xxxxxxxxxxxxx> >; ibis-macro@xxxxxxxxxxxxx
<mailto:ibis-macro@xxxxxxxxxxxxx> 
Subject: [ibis-macro] Re: [ibis-interconn] Re: Proposed changes on
reference connections for BIRD189

 

Why?

 

Walter Katz

wkatz@xxxxxxxxxx <mailto:wkatz@xxxxxxxxxx> 

978.461-0449 x 133

Mobile 303.335-6156

 

From: ibis-interconn-bounce@xxxxxxxxxxxxx
<mailto:ibis-interconn-bounce@xxxxxxxxxxxxx>
[mailto:ibis-interconn-bounce@xxxxxxxxxxxxx] On Behalf Of Muranyi, Arpad
Sent: Wednesday, November 29, 2017 11:01 AM
To: IBIS-Interconnect <ibis-interconn@xxxxxxxxxxxxx
<mailto:ibis-interconn@xxxxxxxxxxxxx> >; ibis-macro@xxxxxxxxxxxxx
<mailto:ibis-macro@xxxxxxxxxxxxx> 
Subject: [ibis-interconn] Re: Proposed changes on reference connections
for BIRD189

 

Walter,

 

Thanks only half of the question.  The other half is whether we should

say anything about this in IBIS-ISS.

 

Thanks,

 

Arpad

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

 

From: ibis-interconn-bounce@xxxxxxxxxxxxx
<mailto:ibis-interconn-bounce@xxxxxxxxxxxxx>
[mailto:ibis-interconn-bounce@xxxxxxxxxxxxx] On Behalf Of Walter Katz
Sent: Wednesday, November 29, 2017 9:45 AM
To: IBIS-Interconnect <ibis-interconn@xxxxxxxxxxxxx
<mailto:ibis-interconn@xxxxxxxxxxxxx> >; ibis-macro@xxxxxxxxxxxxx
<mailto:ibis-macro@xxxxxxxxxxxxx> 
Subject: [ibis-interconn] Re: Proposed changes on reference connections
for BIRD189

 

Arpad, Mike,

 

I would expect that anyone delivering these models should have a
regression suite that does a Unit Test on the instantiation of each model
and if it gives warning in HSPICE or any other target SPICE simulator.

 

Walter

 

Walter Katz

wkatz@xxxxxxxxxx <mailto:wkatz@xxxxxxxxxx> 

978.461-0449 x 133

Mobile 303.335-6156

 

From: ibis-interconn-bounce@xxxxxxxxxxxxx
[mailto:ibis-interconn-bounce@xxxxxxxxxxxxx] On Behalf Of Mike LaBonte
Sent: Wednesday, November 29, 2017 10:37 AM
To: IBIS-Interconnect <ibis-interconn@xxxxxxxxxxxxx
<mailto:ibis-interconn@xxxxxxxxxxxxx> >; ibis-macro@xxxxxxxxxxxxx
<mailto:ibis-macro@xxxxxxxxxxxxx> 
Subject: [ibis-interconn] Re: Proposed changes on reference connections
for BIRD189

 

Now I see what you are getting at. Both circuits give the same warning:

 

  **warning** (test.sp:6) Global net name, "gnd", in subckt pin list. The
pin will be connected to the local net. Recommend to not use global net
names in subckt pin lists.

 

Does the idea that someone could put node 0 in the terminal list impact
IBIS? Should IBIS-ISS specifically disallow it? I'm thinking if we said
nothing no one would ever do it.

 

Mike

 

From: ibis-interconn-bounce@xxxxxxxxxxxxx
<mailto:ibis-interconn-bounce@xxxxxxxxxxxxx>
[mailto:ibis-interconn-bounce@xxxxxxxxxxxxx] On Behalf Of Muranyi, Arpad
Sent: Wednesday, November 29, 2017 10:29 AM
To: IBIS-Interconnect <ibis-interconn@xxxxxxxxxxxxx
<mailto:ibis-interconn@xxxxxxxxxxxxx> >; ibis-macro@xxxxxxxxxxxxx
<mailto:ibis-macro@xxxxxxxxxxxxx> 
Subject: [ibis-interconn] Re: Proposed changes on reference connections
for BIRD189

 

Could you also please try:

 

*

V1 1 0 1

X1 1 0 test

R0 1 0 R=50

 

.subckt test 1 0

R1 1 0 50

.ends

 

.end

 

 

Thanks,

 

Arpad

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

 

From: ibis-interconn-bounce@xxxxxxxxxxxxx
<mailto:ibis-interconn-bounce@xxxxxxxxxxxxx>
[mailto:ibis-interconn-bounce@xxxxxxxxxxxxx] On Behalf Of Muranyi, Arpad
Sent: Wednesday, November 29, 2017 9:27 AM
To: IBIS-Interconnect <ibis-interconn@xxxxxxxxxxxxx
<mailto:ibis-interconn@xxxxxxxxxxxxx> >; ibis-macro@xxxxxxxxxxxxx
<mailto:ibis-macro@xxxxxxxxxxxxx> 
Subject: [ibis-interconn] Re: Proposed changes on reference connections
for BIRD189

 

Mike,

 

Thanks for trying it, but that was not the question.  Could you try it
like this:

 

*

V1 1 0 1

X1 1 Top0 test

R0 1 Top0 R=50

 

.subckt test 1 0

R1 1 0 50

.ends

 

.end

 

 

Thanks,

 

Arpad

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

 

From: ibis-interconn-bounce@xxxxxxxxxxxxx
<mailto:ibis-interconn-bounce@xxxxxxxxxxxxx>
[mailto:ibis-interconn-bounce@xxxxxxxxxxxxx] On Behalf Of Mike LaBonte
Sent: Wednesday, November 29, 2017 9:18 AM
To: IBIS-Interconnect <ibis-interconn@xxxxxxxxxxxxx
<mailto:ibis-interconn@xxxxxxxxxxxxx> >; ibis-macro@xxxxxxxxxxxxx
<mailto:ibis-macro@xxxxxxxxxxxxx> 
Subject: [ibis-interconn] Re: Proposed changes on reference connections
for BIRD189

 

This works without error or warning in HSPICE 2016.06-1:

 

*

V1 1 0 1

X1 1 test

 

.subckt test 1

R1 1 0 50

.ends

 

.end

 

Mike

 

From: ibis-interconn-bounce@xxxxxxxxxxxxx
<mailto:ibis-interconn-bounce@xxxxxxxxxxxxx>
[mailto:ibis-interconn-bounce@xxxxxxxxxxxxx] On Behalf Of Muranyi, Arpad
Sent: Wednesday, November 29, 2017 1:11 AM
To: 'IBIS-Interconnect' <ibis-interconn@xxxxxxxxxxxxx
<mailto:ibis-interconn@xxxxxxxxxxxxx> >; ibis-macro@xxxxxxxxxxxxx
<mailto:ibis-macro@xxxxxxxxxxxxx> 
Subject: [ibis-interconn] Re: Proposed changes on reference connections
for BIRD189

 

Bob,

 

You are correct that IBIS-ISS doesn't mention that using node 0 on
subcircuit definition lines

is prohibited.  I didn't search long enough on the internet to find out
whether HSPICE allows

it or not, but in my search I found a few other SPICE flavors which
specifically do NOT allow it.

So we need to research this a little more about HSPICE, because IBIS-ISS
is basically a subset

of that.

 

Anyway, even if it is allowed, I wonder how useful it actually is.  Node 0
is a global node which

is visible in the entire simulation netlist, so I don't see a lot of need
for having to pass it in/out

of a subcircuit through its definition line.  I can only think of one
isolated use.  If someone wants

to use different subcircuit calls for a simulation through .alter
statements, I could see that the

netlist that instantiates these different subcircuits could get grounded
connections from some

of these subcircuit terminals but not others, depending on which one is
instantiated at any given

time, but I think the same results could be achieved in different ways
too.

 

Aside from that, let's look at your examples, assuming that it is allowed.

 

"Case 1 - only node "0" are declared with A_gnd (to occupy a position)

5 A_gnd
7 A_gnd"

 

This is an illegal case, because BIRD189 states that for File_IBIS-ISS,
you must has as many terminal

lines as the number of subcircuit terminals, i.e. all terminals must have
a corresponding terminal line.

 

"Case 2  Actual nodes are electrically shorted by connections to node 0

5 Pullup_ref   signal_name VDD | this is correct for ECL relative to
global GND)
7 Pulldown_ref signal_name VSS"

 

I would say this case should also be illegal, on multiple accounts.  One
is that both terminal 5 and 7

in the subcircuit definition line are connected to node0, consequently the
buffer's two supply

connections are shorted.  Second, these connections might end up with the
famous "voltage source

or inductor loop" error in most SPICE simulators, because the node0
connection from the subcircuit

definition line is trying to feed the buffer's ***_ref nodes, which could
be fed by an ideal voltage

source if not powered through a package model.

 

Case 3a is OK, but kind of stupid in a way, because terminals 5 and 7 are
connected to node0 from

both the inside and the outside of the subcircuit.  Terminals 2 and 3
might be "signal terminals",

which can be shorted to node0 if so desired, but that is up to the model
maker to decide.

 

Case 3b is doing the same with terminals 2 and 3, so that would be OK, but
terminals 5 and 7 have

the same problem as case 2.

 

Case 4 is what I really had in mind for this whole thing (provided that
all subcircuit terminals have

a corresponding terminal line).  Make the node0 connection to the
subcircuit from the outside

ONLY, regardless of whether the subcircuit terminal is a signal terminal,
supply terminal, or reference

terminal.  I would favor to only allow this type of connection.  Maybe we
need to spell this out

in the BIRD more clearly so people wouldn't end up doing what you are
doing in the other examples.

I was under the impression that the subcircuit definition line will never
have "0" or its synonyms,

but if it turns out that IBIS-ISS does not prohibit that, we would not be
able to avoid that from

ever happening.  So we might just have to add another warning to BIRD189
that model makers should

be careful not to "mate" subcircuit terminals which are node0 with A_gnd
or any of the supply

Terminal_types on the terminal lines to avoid shorted voltage supplies.
This would address your

question:

 

"Do we allow IBIS-ISS node "0" connections with any other rail
Terminal_type
besides A_gnd? (Case 2, 3b)"

 

Regarding:

 

"Do we allow IBIS-ISS A_gnd Terminal_type designation for any rail node
that
is not node "0"? (Cases 3, 4)
If so, why not for terminals 1 .. N in Touchstone?"

 

I don't see why we shouldn't allow those subcircuit terminals or ports to
be connected

to node0 on the terminal line (including 1.N for File_TS models).  But I
wouldn't be

opposed at prohibiting that either.  The problem, however, is that for
File_IBIS-ISS

we have no idea which terminal is non-reference or which terminal is
reference.  So

the rule would go nowhere, because it can't be enforced.  For File_TS, the
rule would

make more sense, because we DO know that the N+1th terminal is the
reference

terminal, therefore we can have a rule that only that one may have A_gnd
and the

rest must not have it.

 

That's why I wrote the proposal as I did.  Anything goes for File_IBIS-ISS
but only the

N+1th terminal can have A_gnd for Files_TS.

 

So, to summarize, in my mind, subcircuits do NOT have node0 on the
subcircuit

definition line.  But if this is legal in IBIS-ISS, we can't avoid it,
therefore we need to

address this situation in BIRD189.  I would prefer to not allow node0 on
the subcircuit

definition line, but that may not be possible.  If it is not preventable,
we may need to

add a warning (or rule) to BIRD189 to let the model maker know that they
should not

use A_gnd or Pullup_ref, Pulldown_ref, Power_clamp_ref, Gnd_clamp_ref,
Buffer_Rail,

Ext_ref on terminal lines which correspond to IBIS-ISS subcircuit
terminals that have

node0 on them.  We could actually parse this condition, if we are willing
to have the

parser look inside the subcircuit files.  Since we don't know the meaning
of the

subcircuit terminals which are not node0, this is the only rule we could
define for

File_IBIS-ISS.  All other terminals should be allowed to be connected to
A_gnd, or 

any of the other Terminal_types I listed above.

 

For File_TS, I would only allow A_gnd for the N+1th terminal line.  There
is no need to

connect any of its other ports to node0, because the model maker already
has the

Unused_port_termination option to place a "short" (a very small resistor)
between

any of the ports and the reference terminal.  But if anyone insists that
we should

allow the non-reference terminals to be connected to node0, I would not
oppose

it.

 

Thanks,

 

Arpad

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

 

From: ibis-interconn-bounce@xxxxxxxxxxxxx
[mailto:ibis-interconn-bounce@xxxxxxxxxxxxx] On Behalf Of Bob Ross
Sent: Tuesday, November 28, 2017 9:10 PM
To: 'IBIS-Interconnect' <ibis-interconn@xxxxxxxxxxxxx
<mailto:ibis-interconn@xxxxxxxxxxxxx> >; ibis-macro@xxxxxxxxxxxxx
<mailto:ibis-macro@xxxxxxxxxxxxx> 
Subject: [ibis-interconn] Re: Proposed changes on reference connections
for BIRD189

 

Arpad,

 

You may be correct about node 0 on the .subckt definition line, but I do
not see that restriction in IBIS-ISS.

 

However, the examples are changed in the .subckt nodes such that VXX is
the same as node 0 with this line.

 

VXX   VXX   0   0.0

 

(node 0 is inside)

 

Bob

 

From: ibis-interconn-bounce@xxxxxxxxxxxxx
<mailto:ibis-interconn-bounce@xxxxxxxxxxxxx>
[mailto:ibis-interconn-bounce@xxxxxxxxxxxxx] On Behalf Of Muranyi, Arpad
Sent: Tuesday, November 28, 2017 5:38 PM
To: Bob Ross; 'IBIS-Interconnect'; ibis-macro@xxxxxxxxxxxxx
<mailto:ibis-macro@xxxxxxxxxxxxx> 
Subject: [ibis-interconn] Re: Proposed changes on reference connections
for BIRD189

 

Bob,

 

I think node 0 and its synonyms are not allowed on .subckt definition
lines.  So a lot of your examples fall out for that reason.  Could you
rewrite your questions without them?

 

Thanks,

 

Arpad

======

 

 

 

Sent from my Verizon, Samsung Galaxy smartphone

 

 

-------- Original message --------

From: Bob Ross <bob@xxxxxxxxxxxxxxxxx <mailto:bob@xxxxxxxxxxxxxxxxx> > 

Date: 11/28/17 6:58 PM (GMT-06:00) 

To: 'IBIS-Interconnect' <ibis-interconn@xxxxxxxxxxxxx
<mailto:ibis-interconn@xxxxxxxxxxxxx> >, ibis-macro@xxxxxxxxxxxxx
<mailto:ibis-macro@xxxxxxxxxxxxx>  

Subject: [ibis-interconn] Re: Proposed changes on reference connections
for BIRD189 

 

All,

Questions and comments.

1. The EDA tool may already have a node 0 reference terminal.  That
becomes
a "virtual reference" everywhere, whether or not there is a corresponding
physical terminal.

2. The stated rule is:

"Terminal_type A_gnd is not required under File_TS or File_IBIS-ISS.  If
present under File_TS, it may be used only once on the N+1th terminal
line.
If present under File_IBIS-ISS, it may be used any number of times on any
of
the terminal lines."

For File_IBIS-ISS, we should not have any qualifiers or values.  Whereever
A_gnd is declared, it a global reference terminal.  For example, nodes at
locations 5 and 7 are "0" would have these terminals without any
qualifiers:

Consider
.subckt model_name  io  vdd  vss  vdd1 VXX  vee1  VXX 

Case 1 - only node "0" are declared with A_gnd (to occupy a position)

5 A_gnd
7 A_gnd

Case 2  Actual nodes are electrically shorted by connections to node 0

5 Pullup_ref   signal_name VDD | this is correct for ECL relative to
                               | global GND).
7 Pulldown_ref signal_name VSS

Case 3:  Use A_gnd to short an existing rail to global ground:

3a

2 A_gnd   : existing non-node 0 nodes
3 A_gnd

5 A_gnd
7 A_gnd

Or 3b

2 A_gnd 
3 A_gnd

5 Pullup_ref   signal_name VDD
7 Pulldown_ref signal_name VSS

Case 4:

No internal node "0" node
.subckt model_name  io  vdd  vss  vdd1  VSS1  vee1   VEE2

5 A_gnd
7 A_gnd

----

An expected connection is shown in Case 1.

Do we allow IBIS-ISS node "0" connections with any other rail
Terminal_type
besides A_gnd? (Case 2, 3b)

Do we allow IBIS-ISS A_gnd Terminal_type designation for any rail node
that
is not node "0"? (Cases 3, 4)
If so, why not for terminals 1 .. N in Touchstone?

Do we allow IBIS-ISS A_gnd Terminal_type designation to any rail terminal
that is not node "0" AND there is no node "0"? (Cases 4)
If so, why not for terminals 1 .. N in Touchstone?

I think the stated rule allows all four cases, but not the Touchstone
exception.

Bob


-----Original Message-----
From: ibis-interconn-bounce@xxxxxxxxxxxxx
<mailto:ibis-interconn-bounce@xxxxxxxxxxxxx> 
[mailto:ibis-interconn-bounce@xxxxxxxxxxxxx] On Behalf Of Muranyi, Arpad
Sent: Tuesday, November 28, 2017 1:32 PM
To: IBIS-Interconnect (ibis-interconn@xxxxxxxxxxxxx
<mailto:ibis-interconn@xxxxxxxxxxxxx> );
ibis-macro@xxxxxxxxxxxxx <mailto:ibis-macro@xxxxxxxxxxxxx> 
Subject: [ibis-interconn] Proposed changes on reference connections for
BIRD189

Hello Everyone,

I am sending this to both email reflectors to  make sure no one is left
out.

As most of you may already know, I made a proposal in today's ATM
teleconference on how to modify BIRD189 to take care of the reference
connections for File_TS and File_IBIS-ISS.  Based on the discussions and
suggestions in the ATM meeting today, I prepared a new draft of BIRD189
which is in the attachment.  This is based on the most recent
"bird189.5_draft11_v1.docx" file.  I accepted all changes and created  a
new
file with tracking turned on, so that my proposed text could be found
easily.  This is now called "bird189.5_draft11_v2.docx" and is in the
attachment.

I understand that there may be a few other places which may need updating,
such as the tables, but I will leave that up to people who are more
familiar
with the editorial procedures on the document.  Also, I think we should
agree to this proposal first before making far reaching changes to the
rest
of the document.

Please review this proposal before the Interconnect teleconference
tomorrow.
I hope that we should be able to get this topic behind us in the meeting
tomorrow.

Questions, comments are welcome, as always...

Thanks,

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

------------------------------------------------------------------
      The IBIS Ad Hoc Interconnect Task Group Mailing List

Archives are available at:     
                //www.freelists.org/archives/ibis-interconn

TO UNSUBSCRIBE:
        Send a message to "ibis-interconn-request@xxxxxxxxxxxxx
<mailto:ibis-interconn-request@xxxxxxxxxxxxx> " 
        with a subject of "unsubscribe"

To administer your subscription status from the web, visit:
                //www.freelists.org/list/ibis-interconn

Meeting minutes and files are available; visit:
                http://www.ibis.org/interconnect_wip/

PNG image

Other related posts:

  1. Home
  2. ibis-macro
  3. Archive
  4. 11-2017