[ibis-macro] Re: Node "0" in IBIS, IBIS External Model, IBIS Interconnect Models
- From: "Muranyi, Arpad" <Arpad_Muranyi@xxxxxxxxxx>
- To: "ibis-macro@xxxxxxxxxxxxx" <ibis-macro@xxxxxxxxxxxxx>, "ibis-users@xxxxxxx" <ibis-users@xxxxxxx>, "ibis-interconn@xxxxxxxxxxxxx" <ibis-interconn@xxxxxxxxxxxxx>
- Date: Fri, 8 Aug 2014 17:05:49 +0000
Brad,
I would like to make two comments for discussion.
#1) There seems to be two ways to achieve this goal. One is
to prohibit the usage of node names which have ideal node 0
meaning (node0, GND, GROUND, etc...) when the ISS subcircuit is
used for package and on-die interconnect modeling. The other
way is to allow these node names in the subcircuit, but interpret
them as if they were just like any other ordinary node names.
We already have the second approach in ISS for nodes which are
declared as .global, so for consistency this would be an easy
rule to extend for the ideal 0 node and its synonyms. But the
problem with this approach is that it is not enforceable, i.e.
the parser can't check and warn anybody about this. If we want
the parser to be able to issue messages, we would be better off
prohibiting the usage of these special node names and issue warnings
or errors if they appear in the subcircuit.
#2) I will still need to do some research on this, but I vaguely
remember that there are some rules in SPICE regarding the usage
of global node names in subcircuit definitions. I am concerned
a little that some of these rules may be in conflict with allowing
the global and ideal ground node names on the subcircuit definition
line. Like I said, this needs to be researched some before I can
say anything definitive, but this is something to keep in mind.
Thanks,
Arpad
======================================================================
From: ibis-interconn-bounce@xxxxxxxxxxxxx
[mailto:ibis-interconn-bounce@xxxxxxxxxxxxx] On Behalf Of Bradley Brim
Sent: Thursday, August 07, 2014 1:34 AM
To: ibis-macro@xxxxxxxxxxxxx; ibis-users@xxxxxxx; ibis-interconn@xxxxxxxxxxxxx
Cc: wkatz@xxxxxxxxxx
Subject: [ibis-interconn] Re: Node "0" in IBIS, IBIS External Model, IBIS
Interconnect Models
Hello all,
This is a message to solicit feedback to the IBIS interconnect task group. It
is not to initiate an extended e-mail exchange among this entire distribution
list. Please consider replying to
ibis-interconn@xxxxxxxxxxxxx<mailto:ibis-interconn@xxxxxxxxxxxxx> with any
thoughts you wish to share.
The interconnect task group has been working on a BIRD to enable more general
package/on-die interconnect models inside the IBIS topology through the
application of ISS subcircuits. ISS supports the application of global ground.
There is a vote scheduled for 8:00am this Wednesday August 13 in the
interconnect task group meeting to decide whether or not we allow access to
global ground for this new package/on-die interconnect modeling. We delayed the
vote because there are only a handful of active participants in this task group
and we wished to allow for broader comment before making such an important
decision. Views among the active participants vary, as we suspect they will
throughout the IBIS user/developer community.
Cadence believes that global ground should not be accessible from within IBIS
package/on-die interconnect models. We do not believe an industry standard
should allow access to any electrical node outside the topology of IBIS except
for connectivity through one of the formally declared external pins. Any
current that flows to global ground in the electrical model that does not
connect through a pin in the external pin list is non-physical and incorrect.
If global ground access is disallowed for these new models, a very small
incremental effort is required by model developers to apply package/on-die
interconnect models which now apply global ground (see examples below).
We believe it would be a benefit to the IBIS community to revisit the buffer
portion of the specification formally disallow access to global ground and
clarify all local references, such as to where C_comp or legacy package pin
capacitances are referenced. We perceive this activity as a separate, though
related, discussion and wish to focus now on the decision for interconnect. If
global ground is available in the new package/on-die interconnect portion we
perceive much less value in revisiting the buffer portion of the spec to
clean-up references and global ground issues.
Thanks in advance for sharing your thoughts with the interconnect task group,
-Brad Brim
The motion being considered is to disallow the application of global ground for
the new IBIS Package/On-die Interconnect modeling capability. The motion
addresses only the new section of the specification we are now considering.
Specifically, it does not resolve questions such as: to where is C_comp or a
legacy package pin capacitances referenced. Further, the motion does not
restrict the application of global ground for other present or future ISS
applications. The motion does not include a proposed implementation, though a
few alternatives are discussed below.
The only ISS element that implicitly applies global ground is the S-element in
its N-node form. The proposal could either (a) disallow application of this
form of the S-element, or (b) impose two requirements: (1) model maker
specification of a reference terminal to replace any occurrence of global
ground, and (2) EDA tool application of this terminal as local reference
instead of the implicit global ground.
It seems there are two potential implementations. One choice would be to
consider all occurrences of what would otherwise be global ground (i.e. '0',
GROUND, GND, !GND, GND!) as any other locally-scoped node. These nodes would be
connected to each other within the subcircuit but outside the domain of the
subcircuit would remain floating unless explicitly exposed in the external node
list and connected to something in a higher level circuit. The N-node form of
the S-element would be disallowed. Alternately, an implementation similar to
that described above as option (b) for the N-node form of the S-element could
be pursued.
It is likely a local reference terminal will require model maker specification
to enable termination of unused terminals for Package/On-die Interconnect
Models. This terminal could also serve as local reference for any explicit or
implicit formerly global ground if an EDA tool solution is pursued.
If the choice of explicitly exposing global ground nodes is chosen, then EDA
tools are not likely to require any changes for immediate support of this new
Package/On-die Interconnect modeling capability; except for the model developer
convenience feature being considered for terminating unused terminals. A small
incremental burden of exposing these nodes in subcircuit calls will be required
from model developers for all these new models. If the path of EDA tool mapping
of global ground to a local reference terminal is pursued, then all EDA tools
will require significant enhancement to support the new capability. Due to
development resource allocations and commercial release schedule
synchronization it is likely to require a year or more for the capability to be
broadly supported once the specification becomes available. The timeframe for
support of terminating unused terminals may be similarly long even for the
explicit exposure choice, though the effort seems significantly less because no
updating of model maker specified netlists will be required prior to internal
consumption by the EDA tool.
A ISS subcircuit could presently be referenced as
xThruPath in out
For any of the following cases
1. Node 0 global ground nodes
.subckt ThruPath 1 4
L1 1 2 1pH
L2 2 3 1pH
L3 3 4 1pH
C1 2 0 1fF
C2 3 0 1fF
.ends
2. Alternate global ground nodes
.subckt ThruPath 1 4
L1 1 2 1pH
L2 2 3 1pH
L3 3 4 1pH
C1 2 GND 1fF
C2 3 GROUND 1fF
.ends
3. Implicit reference node using global ground
.subckt ThruPath 1 2
S1 1 2 mname=thru
.model thru S 2 TSTONEFILE='TSthru.s2p'
.ends
4. Explicit reference node using global ground
.subckt ThruPath 1 2
S1 1 2 GND mname=thru
.model thru S 2 TSTONEFILE='TSthru.s2p'
.ends
5. Explicit reference nodes using global ground
.subckt ThruPath 1 2
S1 1 0 2 0 mname=thru
.model thru S 2 TSTONEFILE='TSthru.s2p'
.ends
6. Explicit reference nodes using various forms of global ground
.subckt ThruPath 1 2
S1 1 GND 2 GROUND mname=thru
.model thru S 2 TSTONEFILE='TSthru.s2p'
.ends
If the present global ground nodes ('0' and its aliases) are treated the same
as any other locally-scoped node with required explicit exposure in the
subcircuit node list, the above forms would change as follows:
1. Node 0 as global ground
xThruPath in out ref_node
.subckt ThruPath 1 4 0
L1 1 2 1pH
L2 2 3 1pH
L3 3 4 1pH
C1 2 0 1fF
C2 3 0 1fF
.ends
2. Alternate nodes as global ground
xThruPath in out local_ref local_ref
.subckt ThruPath 1 4 GND GROUND
L1 1 2 1pH
L2 2 3 1pH
L3 3 4 1pH
C1 2 GND 1fF
C2 3 GROUND 1fF
.ends
3. Implicit reference node using global ground would be a disallowed form.
4. Explicit reference node using global ground
xThruPath in out ref
.subckt ThruPath 1 2
S1 1 2 GND mname=thru
.model thru S 2 TSTONEFILE='TSthru.s2p'
.ends
5. Explicit reference nodes global ground
xThruPath in out ref
.subckt ThruPath 1 2 GND
S1 1 0 2 0 mname=thru
.model thru S 2 TSTONEFILE='TSthru.s2p'
.ends
6. Explicit reference nodes using various forms of global ground
xThruPath in out ref ref
.subckt ThruPath 1 2 GND GROUND
S1 1 GND 2 GROUND mname=thru
.model thru S 2 TSTONEFILE='TSthru.s2p'
.ends
Other related posts:
