[ibis-macro] Minutes from the 14 November ibis-atm meeting

  • From: Curtis Clark <curtis.clark@xxxxxxxxx>
  • To: IBIS-ATM <ibis-macro@xxxxxxxxxxxxx>
  • Date: Mon, 20 Nov 2017 13:31:06 -0500

Minutes from the 14 November ibis-atm meeting are attached.
IBIS Macromodel Task Group

Meeting date: 14 November 2017

Members (asterisk for those attending):
ANSYS:                      * Dan Dvorscak
                            * Curtis Clark
Broadcom (Avago):             Xingdong Dai
                              Bob Miller
Cadence Design Systems:     * Ambrish Varma
                              Brad Brim
                              Kumar Keshavan
                              Ken Willis
eASIC:                        David Banas
                              Marc Kowalski
Ericsson:                     Anders Ekholm
GlobalFoundries:              Steve Parker
IBM                           Luis Armenta
                              Trevor Timpane
Intel:                        Michael Mirmak
Keysight Technologies:        Fangyi Rao
                            * Radek Biernacki
                              Ming Yan
Maxim Integrated Products:    Hassan Rafat
Mentor, A Siemens Business:   John Angulo
                            * Arpad Muranyi
Micron Technology:          * Randy Wolff
                            * Justin Butterfield
SiSoft:                       Walter Katz
                              Todd Westerhoff
                              Mike LaBonte
Synopsys:                     Rita Horner
                              Kevin Li
Teraspeed Consulting Group:   Scott McMorrow
Teraspeed Labs:             * Bob Ross
TI:                           Alfred Chong

The meeting was led by Arpad Muranyi.  Curtis Clark took the minutes.


- Arpad reviewed the schedule for upcoming ATM meetings.  The group decided to
  cancel the meetings on December 26th and January 2nd.  All other meetings,
  including next week's, will be held as usual.

Review of ARs:

- Arpad to send the draft of BIRD165.1 to Mike L. for posting to the ATM
  - Done.
Call for patent disclosure:

- None.

Review of Meeting Minutes:

- Arpad: Does anyone have any comments or corrections? [none]
- Dan: Motion to approve the minutes.
- Randy: Second.
- Arpad: Anyone opposed? [none]

New Discussion:

- Discussion:  Bob said he thought the posted draft looked good and was ready to
  submit.  Radek agreed.  Arpad noted that Walter had said in last week's
  meeting that he thought it was ready.  Arpad said he would submit it to the
  Open Forum as BIRD165.1.  No one objected.
BIRD189 - File_TS0 issues.
- Radek: Last week's discussion was continued in the Interconnect meeting.
  - Could someone summarize those discussions for those of us who didn't
    attend the Interconnect meeting?
- Arpad: [sharing the minutes from the Interconnect meeting]
- Radek: [reviewing and responding]
  - Mixing File_TS and File_TS0 isn't the problem.
  - File_TS0 itself is the problem.
  - I don't oppose the File_TS0 idea altogether.  In its current form, I think
    think it's a mistake because it lets a component include a node outside
    the span of the nodes covered by the interconnect model.
  - If a draft required one of the power rails or something else to connect to
    ideal node 0, to expose it to the rest of the circuit being modeled, that
    would be okay.  Otherwise we have to make it clear that there are severe
    restrictions on the Touchstone data if we want to ensure it's used
    unambiguously and correctly.
- Bob: You could oppose File_TS0 entirely, or you could accept File_TS0 but
       acknowledge that one has to be careful when using it.  The use of it
       is the technical concern right now.
  - Do you oppose it entirely?
- Radek: The usage for File_TS0 is very clear, because the draft says that
         reference is connected to node 0.
  - What I'm saying is that if node 0 is not spanned by the interconnect
    modeling package, then it's entirely outside the modeling area.  In that
    case there are very strict restrictions on the data in the Touchstone file.
    People need to be aware of the restrictions on allowable Touchstone data.
- Arpad: Radek, what would you propose instead of File_TS0?
  - It sounds like you're unhappy with File_TS0, but how would you solve the
    issue it was intended to address?
  - What if we just found a way to do everything with a File_TS (N+1 terminals)
    and have the user explicitly connect the N+1st terminal to node 0?
    - How would that be different from File_TS0?  Regardless of the File_TS or
      File_TS0 syntax, the user could still make a mistake and connect the rest
      of their model improperly.
- Radek: The question is what do we want to do?
  - If you really want that connected to global ground, then either:
    - Global ground has to be present in the set of nodes spanned by the model.
      - or
    - The connection to global ground has to have no effect.
  - Whatever we decide must be unambiguous and correct.
  - I could propose removing File_TS0 altogether.
    - Then you have the N+1 nodes (File_TS), and the N+1st node is one of the
      nodes used for connections.
    - Regardless of what we call that global ground node, if we use it we have
      to make sure it's present in all the pieces of the interconnect model.
  - I know Arpad had suggested using A_gnd as that N+1st node, but then is that
    the only component that connects to A_gnd?
  - If this N+1st reference node can be connected to a node outside of the
    modeling area, then there must be no current through that node.  That
    terminal must be internally isolated from the rest of the terminals in
    the component.
  - Let's say you have a resistor that connects nodes 1 and 2, and you have a
    node 3 that is isolated from the first 2.  So you make a two-port model with
    port 1 (nodes 1 and 3) and port 2 (nodes 2 and 3).  This configuration
    results in Z matrix non-existent, or Y matrix singular.  Typical
    S-parameter data in a Touchstone file has no such restriction.
  - This is the problem.  If you had some connection between nodes 1 and 3
    or nodes 2 and 3 then you would get current flowing through node 3.  The
    only case when there's no current through node 3 is the one I just
    described (above).  If you have a configuration like that then you can
    freely connect node 3 to any node (including node 0).  But if you don't
    obey this restriction then you get ambiguous results depending on what is
    done elsewhere in the external circuit.
- Arpad: I'd like to hear a proposal to resolve this.  I think we've gone over
         the problem statement multiple times at recent meetings.
- Bob: I'm not sure it's fixable.  Here's a problem: If one of the package
       models uses node 0 as its reference, and it's cascaded with a second
       package model that uses one of the traces as its reference, then you have
       an incompatibility.
  - We can just advise about this with a warning in the spec.
  - That second model might be an IBIS-ISS model with a node 0 reference.
- Arpad: This situation reminds me of the referencing discussions related to
         the [Pullup Reference], [Pulldown Reference], etc.  We discussed node 0
         in that context too.
  - It sounds like Radek's concern is that if one of the interconnect models
    touches node 0 and nothing else in the circuit does, then you'd have a
    portion of the circuit disconnected from another portion.
- Radek: Exactly, that's the origin of the problem.
- Arpad: In IBIS, at least one of the voltage sources that supplies the I/V
         curve based buffer will most likely be connected to node 0.  I don't
         know of any simulators that can do things without have the common
         reference somewhere.
- Radek: There's a consequence of the fact that File_TS0 is forcing a connection
         to node 0, because you're not necessarily connecting that node 0
         anywhere else in the simulation.
- Arpad: Doesn't that problem exist elsewhere in the spec., too?
  - What if someone uses A_gnd in [External Model], couldn't you have the same
  - I'm not sure this is the place to fix this issue.  Would we have to rewrite
    the whole spec?
- Radek: If we use the text I emailed out (included in last week's minutes),
         that's a clear statement to tool and model makers of the issue and
  - If we say nothing we are hiding our heads in the sand.
  - People won't always know what they're doing if we don't give them any
  - Originally IBIS was constructed around node 0.
  - [Voltage Range] was specified between global ground and the pullup_ref,
    for example.
  - We have moved on from that a bit and are now talking about PDNs and pins
    that are connected.  We have editorial work on cleaning up the referencing
    issues.  We've been working on that and it is not finalized.
  - This File_TS0 would be trying to enforce a mechanism that runs counter to
    these updates.
  - We have the same issue with an IBIS-ISS model that might include a
    connection to node 0 internally.
- Arpad: I'm still not sure this is the place to address this.
  - In SPICE type simulators, if your netlist is never touching node 0 then you
    get a "no DC path to ground" warning.
  - So there's already an implicit expectation of one node somewhere being
    related to node 0.
- Radek: You wouldn't arbitrarily take one terminal of your circuit and connect
         it to a totally different location and expect the results to stay the
         same.  But we are trying to give designers a way to do it without
         mentioning that this could be incorrect.
- Arpad: Say you have a mother board design and you're going out of your way to
         model all the power and ground planes.  So none of your buffers is
         connected to node 0, they're all connected to your non-ideal planes.
         At some point, no matter what you do, the VRM model or some other
         source ends up tied back to node 0.
  - If that connection to node 0 already exists somewhere in the circuit, is
    this really an issue?
- Radek: Yes, the issue is that you cannot arbitrarily grab one terminal and
         connect it to some outside circuitry, and that's what this is trying
         to do.
  - Only if it's known and enforced that there is no current flowing under all
    possible external connections, then you can freely connect it anywhere.
- Bob: Radek raises the flag.
  - But going in the other direction, we could have everything specified
    relative to local references, with no node 0 declared in the modeling area
    ([Model], on-die interconnect, package), and Arpad is pointing out that
    some VRM somewhere would be hooking up the rail terminals with respect to
    a reference ground.  But anywhere else along the path being simulated could
    be floating, and any place along that path where you hard code a connection
    to node zero could be corrupting the path.
- Radek: Your scenario would be a good place not to use File_TS0.  Use the
         File_TS and the N+1st is one of the terminals in the modeling area.
- Discussion: The group discussed two different scenarios.  Arpad proposed an
  example of a two port transmission line's S-parameter data.  He said that
  could be the same as an ideal transformer with two independent coils connected
  across the two ports (2N case, independent references).  He asked if you then
  go to common reference (N+1 case) don't you have the information needed to
  model the voltage relationships between port 1 and port 2?  Radek said it was
  a mistake to assume such a model could give you the voltage information you
  needed without any regard for where the reference terminal were connected.
  Bob said he was concerned about the validity of Radek's proposed restriction
  text.  Bob proposed a one port example in which a resistor was connected
  between terminal 1 and the reference terminal.  He said current would indeed
  flow to node 0 if that were the reference terminal.  Radek said this example
  illustrated the problem.  One could not expect to connect the reference
  terminal to any arbitrary location without affecting the results, unless the
  resistor's value was infinite (reference terminal isolated from terminal 1).
  Radek said this situation could be modeled as a two port, with the resistor
  connecting terminals 1 and 2 and the third terminal a common reference and
  isolated from the first two.  This configuration would meet the requirements
  of Radek's proposed restriction text.
- Arpad: Can we fix this issue with a statement about something that the model
         maker should be aware of?  I agree with Bob that whether it's node 0
         or some other reference node the constraints should be the same.
- Radek: My text is a precise statement of the restriction on the Touchstone
         data used with File_TS0.
- Arpad: Thank you all for joining.

AR: Arpad to submit BIRD165.1 to the Open Forum.

Next meeting: 21 November 2017 12:00pm PT

IBIS Interconnect SPICE Wish List:

1) Simulator directives

Other related posts:

  • » [ibis-macro] Minutes from the 14 November ibis-atm meeting - Curtis Clark