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@freelists.org [mailto:ibis-interconn-bounce@freelists.org] On Behalf Of Bradley Brim Sent: Thursday, August 07, 2014 1:34 AM To: ibis-macro@freelists.org; ibis-users@eda.org; ibis-interconn@freelists.org Cc: wkatz@sisoft.com 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@freelists.org<mailto:ibis-interconn@freelists.org> 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 -- This message has been scanned for viruses and dangerous content by MailScanner, and is believed to be clean. -------------------------------------------------------------------- |For help or to subscribe/unsubscribe, e-mail mikelabonte@eda-stds.org |or ibis-request@eda-stds.org | |IBIS reflector archives exist under: | | http://www.eda-stds.org/ibis/email_archive/ Recent | http://www.eda-stds.org/ibis/users_archive/ Recent | http://www.eda-stds.org/ibis/email/ E-mail since 1993Received on Fri Aug 8 10:06:34 2014
This archive was generated by hypermail 2.1.8 : Fri Aug 08 2014 - 10:07:13 PDT