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

  • From: Curtis Clark <curtis.clark@xxxxxxxxx>
  • To: IBIS-ATM <ibis-macro@xxxxxxxxxxxxx>
  • Date: Wed, 29 Nov 2017 19:48:58 -0500

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

Meeting date: 28 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
SPISim:                     * Wei-hsing Huang
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 plans to
  cancel the meetings on December 26th and January 2nd.  All other meetings
  in December will be held as usual.

Review of ARs:

- None.
Call for patent disclosure:

- None.

Review of Meeting Minutes:

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

New Discussion:
BIRD189 - File_TS reference terminal connection to node 0?
- Arpad: [Sharing his recent email describing his new proposal]
  - Background: My observation is that even if we make a note or warning about
    consistency of usage, "either use node 0 as a reference for everything or
    not at all", we will have trouble in practice.
  - Suggesting or enforcing consistency requirements is impossible if the user
    has models from multiple vendors in the same simulation.
  - Also, we aren't going to change the IBIS-ISS specification now and disallow
    an IBIS-ISS subcircuit from connecting to node 0 internally, so we have
    another consistency issue.
  - [sharing a picture of a 4 port (5 Terminal) package connecting two power
     pins to two power pads]
    - If we don't provide a way for the user to connect the N+1 (5th) terminal
      to node 0, someone might be tempted to use their Vss pin as the reference.
      But that would essentially short that port with its own reference
      (that port's two terminals would be the same).
  - Therefore, I think we need a way to specify ideal node 0 as a reference.
  - Proposal:
    - New Terminal_type called Ref_node. (used to connect to ideal node 0)
    - New Terminal_type_qualifier called node_name.
    - New Qualifier_entry rule.  When the Terminal_type_qualifier is node_name
      the <pin_name_entry> shall be A_gnd.  (use A_gnd from [External Model]).
    - New rule: Aggressor_Only is not allowed with Terminal_type Ref_node.
    - At the end of the Aggressor_Only section add the following rule and 
        Terminal_type Ref_node is not required for File_TS or File_IBIS-ISS, but
        if present, File_TS may only have it only on the N+1th terminal line
        (once), while File_IBIS-ISS may have it on any of its terminal lines any
        number of times.
        Important:  It is highly recommended to not use A_gnd for referencing
        purposes on terminal lines and to not use ideal ground (node0)
        connections inside IBIS-ISS subcircuits.
- Walter: I agree with the functionality you're looking to add, i.e., the
          ability to connect a node in File_TS or multiple nodes for IBIS-ISS
          to node 0.
  - What's the easiest way to implement this in terms of text of the BIRD, ease
    for the model maker, and ease for the EDA tool?
  - What if we just say, "If Terminal_type is A_gnd, then it's ideal node 0."
- Arpad: Just make Terminal_type itself A_gnd?
  - Yes, I think that's simpler, and it would eliminate most of my new rules
    and changes.  But the final rule and warning would largely be the same?
- Walter: I think it would be easier to state that A_gnd is only allowed on
          terminal N+1 of a File_TS.
- Arpad: Walter's suggestion is fine by me.  I'm happy to consider changes.
- Bob: Walter's suggestion is valid and simplifies the proposal.
  - Aggressor_Only is automatically excluded when Terminal_type is A_gnd,
    because it's only for I/O terminals.
- Radek: One of the suggestions I'd made for dealing with the issue of node 0
         appearing in an IBIS-ISS was to make sure node 0 was available to the
         rest of the circuit.
  - But just exposing A_gnd is not the end of the story.  You still have to make
    sure A_gnd (node 0) is present among the nodes the interconnect model is
    actually modeling.
  - If you just let one component connect to A_gnd, you have the same ambiguity
    we discussed regarding File_TS0.
  - We have to be precise about how many components in the model need to be
    connected to the various nodes.  Only the buffer terminals and pin terminals
    can appear only once.  All of the other nodes must appear at least twice in
    order to guarantee proper connectivity.
- Walter: I think one of the requirements (maybe implicit) of BIRD189 is that
          you should be able to use it to wrap package models that are currently
          being developed.  BIRD189 should be able to wrap them in a way that is
          compatible with the way people are making and using them today.
  - I think you'll almost always find that models reference node 0.  They
    reference node 0 on their W-lines, S-parameters, capacitors, etc.
  - It's valid to argue that this may be incorrect for power-aware simulations.
    But even that is not necessarily true.  Scott sent out a very detailed
    explanation about how you can use ground based power-aware simulations and
    get perfectly valid results.
  - So, to say "it is highly recommended to NOT use A_gnd" is incompatible with
    the way people make models today.  I think it would be okay to note that
    since power-aware simulations are becoming more important, one should not
    use A_gnd in an attempt to do power aware simulations without using ground
    based simulation techniques.
- Radek: We are talking about two different things.
  - You make a measurement with respect to your ground (set by the measurement).
  - In the simulation, you either have the same environment as measurement, or
    if you're using that model elsewhere you have to connect that ground to
    something meaningful for your circuit.  You can't just connect it to global
    ground without any regard for the real schematic ground (local ground)
    chosen by the user for the area the interconnect model is covering.
  - If you want to be able to connect to global ground, with no knowledge or
    concern for where the local circuit is, then you need the restrictions on
    the Touchstone data that I defined during the File_TS0 discussions.
- Walter: I'm just trying to quantify the requirement you want.
  - What I said was if you do ground-referenced power modeling, meaning you
    take Vss and everything "0" and tie those nodes to ideal node 0 (so you can
    say Vss is 0V relative to ideal node 0), then everything can work fine.  If
    the simulator did that, then everything is fine and it can do power-aware
    simulations.  You just have to adjust the PDN models for Vdd, but that is
    what people are doing today.
- Arpad: I understand your point.  But I see a dilemma here.
  - We basically have two modeling styles, the ground-referenced style, in which
    all the parasitics are rolled into the upper (power) side of the model, and
    the other style in which power and ground parasitics are kept separate as an
    inductance loop.
  - In order to do one or the other style, the entire simulation deck has to
    follow the same convention.  Can we talk about consistency if the user might
    have to simulate with models from different vendors made one way or the
    other way?  How can we best verbalize the warning?
- Radek: The warning is fine.  You are saying there's an issue, and there's a
         requirement if conditions aren't met.  It tells people it's perhaps
         best not to use node 0.
- Bob: If we go with Arpad's proposal, with Walter's simplifying modification,
       then the warning is easy to check for A_gnd.  Any time A_gnd shows up as
       a Terminal_type, it's a warning.  But catching use of node 0 in IBIS-ISS
       subcircuits or detecting another Touchstone file with an N+1 terminal
       that isn't connected to node 0 is hard, so detecting incompatibilities
       is hard.
- Discussion: The group discussed the wording of a warning sentence to be
  included in the BIRD and arrived at:
    "Power-aware simulations may require that A_gnd NOT be used as a reference
    for interconnect models, or that ideal ground (node0) NOT be used inside
    IBIS-ISS subcircuits."
  With the group's approval, Arpad took the AR to write up a new draft of the
  BIRD for discussion at the Interconnect Meeting the following day.  Bob noted
  that there would be additional vetting to do.
- Arpad: If this BIRD189 discussion now moves back to Interconnect, what topics
         should we discuss next week?
- Walter: I think item #8 (single ended applications of AMI - DDR5) should be
          tabled.  Everyone understands that there are various issues that may
          make it invalid.  But it's still unclear what should be done.
- Discussion: Walter moved to table item #8.  Radek seconded.  No one was
  opposed.  Bob said he thought item #7 (C_comp improvements) should be tabled
  until BIRD189 is finalized.  Bob moved to table item #7.  Walter seconded.
  No one was opposed.
- Arpad: All our topics are tabled.
  - We will continue to hold the meeting and discuss topics as they arise,
    perhaps related to or suggested by Interconnect meetings.
- Mike L.: I'd like to add an item to discuss Forward Error Correction.  I can
           give a presentation on what I've heard from Asia.
- Bob: I'd like to review a presentation by Raymond Chen.
- Arpad: Let's all review that presentation for next week's discussion.
  - Thank you all for joining.

AR: Arpad to prepare BIRD189.5_draft11_v2 with his proposed A_gnd changes.

Next meeting: 05 December 2017 12:00pm PT

IBIS Interconnect SPICE Wish List:

1) Simulator directives

Other related posts:

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