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] On Behalf Of Muranyi, Arpad
Sent: Wednesday, November 29, 2017 9:27 AM
To: IBIS-Interconnect <ibis-interconn@xxxxxxxxxxxxx>; 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>
[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/
