[ibis-macro] Minutes from the 10 April ibis-atm meeting

  • From: Curtis Clark <curtis.clark@xxxxxxxxx>
  • To: IBIS-ATM <ibis-macro@xxxxxxxxxxxxx>
  • Date: Fri, 13 Apr 2018 15:17:18 -0400

 Minutes from the 10 April ibis-atm meeting are attached.
IBIS Macromodel Task Group

Meeting date: 10 April 2018

Members (asterisk for those attending):
ANSYS:                        Dan Dvorscak
                            * Curtis Clark
Cadence Design Systems:       Ambrish Varma
                              Brad Brim
                              Kumar Keshavan
                              Ken Willis
eASIC:                        David Banas
GlobalFoundries:              Steve Parker
IBM                           Luis Armenta
                              Trevor Timpane
Intel:                      * Michael Mirmak
Keysight Technologies:        Fangyi Rao
                            * Radek Biernacki
                              Ming Yan
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
    
The meeting was led by Arpad Muranyi.  Curtis Clark took the minutes.

--------------------------------------------------------------------------------
Opens:

- None.

-------------
Review of ARs:

- Arpad to prepare a new draft of the BIRD to supersede BIRD158.7.
  - Done, draft 4 was sent to ATM and Interconnect shortly after last week's
    meeting.
  
--------------------------
Call for patent disclosure:

- None.

-------------------------
Review of Meeting Minutes:
- Arpad: Does anyone have any comments or corrections? [none]
- Mike L.: Motion to approve the minutes.
- Radek: Second.
- Arpad: Anyone opposed? [none]

-------------
New Discussion:

BIRD189 and BIRD158 related issues:

BIRD158 replacement:
- Discussion: Arpad reviewed the changes in draft 4.  He noted that it contained
  the changes discussed in last week's meeting (removal of "greater than 0" text
  and the new text relating the triangle ground symbols to A_gnd).  Arpad also
  noted that he had replaced the BIRD158.7 text in the "Analysis Path" and 
  "Background Information" with new text specific to this new proposal's changes
  relative to BIRD158.7.

  Radek said the new introductory sections were okay.  However, he noted he now
  had concerns about the removal of the full end-to-end (Fig xxx Entire Analog
  Circuit) figure.  Now that A_gnd has been defined as global ground (node 0),
  the Tx and Rx figures show explicit connections to node 0.  So, the left hand
  side (Tx) and the right hand side (Rx) are connected to node 0.  Without the
  end-to-end figure to indicate that the rest of the channel uses the same
  triangle symbol reference (same node), we might give the impression that the
  node 0 at the Tx and the node 0 at the Rx can provide a path to bypass the
  channel.

  Arpad asked if we lose anything by leaving the figure out.  He noted that this
  BIRD deals strictly with buffer modeling.  He noted that we don't typically
  want cookbook instructions to model makers in the spec itself.  Arpad asked if
  we might defer this discussion until after review of Radek's "Important"
  statement(s) topic.  Radek said we might have to resolve the issues at the
  same time, but if the text in BIRD189 is properly stated then we may not have
  the issue with the figure removal.  Arpad suggested we defer for now.

  Mike L. noted there was a question about whether the original BIRD158 authors
  should be listed as authors of this BIRD.  Arpad said he hadn't simply
  re-listed the BIRD158 authors because he didn't want to presume that they
  would agree with the new BIRD.  Radek had already confirmed his desire to be
  an author on the new BIRD.  Walter noted that he and Todd wanted to be listed
  as authors.  Arpad took an AR to contact Fangyi, the only remaining author
  of BIRD158 who had not yet been asked about being an author of this BIRD.

Radek's "Important" Statements:
- Discussion: Michael M. reviewed the "The Mystery Component" slides (emailed
  to the Interconnect list) he created to illustrate the issue at the core of
  Radek's Important Statements proposal (discussed at the April 6 Interconnect
  Meeting).
    Slide 1: Good Circuit
      - 4 Terminal subcircuit
      - Internal components connected amongst the 4 terminals.
      - Current paths in/out are completely defined by the terminals.
      - Voltage relationships defined by (1,2) (1,3)... (3,4).
    Slide 2: Bad Circuit
      - Same components as the Good Circuit, but one end of the capacitor is
        tied to node 0 (A_gnd).
      - Current paths in/out are not completely defined by the 4 terminals.
      - Voltage relationships not completely defined by (1,2) (1,3)... (3,4).
      - Voltage/Current results may be simulator-dependent.
    Slide 3: Implications and Questions
      - [Bob noted that the first bullet point was incorrect.  It should instead
         say that the behaviors of the Bad and Good Circuit will be identical
         if Terminal 4 is connected to A_gnd in each.  Michael M. agree with
         this correction.  He made the correction in the version sent after the
         meeting.]
  Michael M. asked Radek if the goal of his proposal were to have the EDA tool
  create a five terminal subcircuit in the case of the Bad Circuit and make the
  fifth terminal A_gnd.  Radek said that conceptually you would take the GND
  terminal in Bad Circuit and draw a line to the right to make a fifth terminal
  for the subcircuit.  In practice A_gnd is exposed already because it's global.
  What we need to do is make sure that it's clear how we interpret that
  situation and make sure the user knows when it occurs.  The user/tool has to
  know when it occurs and know that you must facilitate a return path through
  that node.

  Arpad asked why we are discussing the issue.  Since A_gnd (node 0) is a global
  node there is no need to "expose" it at all.  Arpad asked what the user could 
  even do when notified that the subcircuit contained a use of node 0.  Michael
  M. asked if the language we are inserting is a notification to the model maker
  that they risk inconsistent results if they use node 0 in their subcircuit, or
  if it is to tell the tool that if it encounters such a subcircuit then node 0
  must be made available at every level of the circuit hierarchy all the way up
  to the [Pin] level.  Radek said that if node 0 is found anywhere in the
  hierarchy then it must be available at every level, including having a ground
  pin.  It's up to the user to make the final connections, but if the user
  doesn't do that right then it's up to the specification to point out that 
it's 
  a mistake.  The tool should detect the situation and warn the user when the
  condition occurs (node 0 used in the subcircuit).  It's then up to the user to
  make the connections properly to ensure the right return paths.

  Radek noted that he had originally proposed two "Important" paragraphs.  Now
  that A_gnd had been defined as a global node (node 0), those collapsed to one.
  But now we have further extended information about that node:
    - Even if node 0 is not explicitly used, if there is an S-element inside of
      the ISS subcircuit that has N ports and N terminals, then by definition
      node 0 is its reference node.
    - If you have A_gnd being used anywhere in a BIRD189 model, then it's
      exactly the same situation and A_gnd needs to be considered a reference
      terminal throughout the entire modeled area.
  
  Michael M. asked if the spec should strongly recommend that the tool points
  out when node 0 is used in a subcircuit, and that the user should then provide
  the return path.  Bob noted that the parser itself should not dive into the
  IBIS-ISS file, nested includes, etc., to search for node 0.  So, it wasn't
  enforceable in that sense.  The parser can't rewrite the interconnect model to
  expose things, and use of node 0 is legal in IBIS-ISS anyway, so there's
  nothing for the parser to do in this area.  It's up to the EDA tools to figure
  it out.

  Michael M. asked the rhetorical question, "Is there anything for the EDA tool
  to do if node 0 never shows up anywhere in the entire hierarchy?"  Michael and
  Arpad agreed the answer was no.  Michael then asked, "If the Bad Circuit does
  exist in the hierarchy, how will the user know?  Shouldn't the user be 
  notified in that case?"  Arpad reiterated that it wasn't clear what the user
  could do with this information.

  Arpad suggested that Randy's model (discussed in previous meetings) was an
  example of why we would have to be very careful with this "warning" concept.
  Arpad noted that Randy's model contained an Ext_Gnd_Ref node that was the
  actual reference for the transmission lines, etc.  The node 0 appears in his
  subcircuit just as a center-of-the-universe artifact.  If we were to have the
  tool throw a warning over this subcircuit, then the user could be confused and
  do things incorrectly because the Ext_Gnd_Ref is really the reference in
  Randy's subcircuit.  Radek noted that in fact Randy's model did not expose the
  Ext_Gnd_Ref at the top level subcircuit terminals.  Randy agreed that this was
  a model that needed to be corrected, and the Ext_Gnd_Ref should be exposed.
  Randy noted that the capicators to node 0 were very small (on the order of
  atto F), and for practical simulation purposes one could just tie the
  Ext_Gnd_Ref to node 0.  Radek said that even if the capacitors are small, we
  still want to let the user know when that situation occurs.  Arpad again
  suggested the user couldn't do anything about it.  Radek said the BIRD158 end-
  to-end channel figure he wanted to retain was an example of what the user
  could do with the information.  The figure showed explicitly that since the 
Tx 
  and Rx use A_gnd (triangle reference symbol) then the rest of the channel had
  to use it too.  Arpad said the user could only do this if they had control
  over the board level connections.

  Walter suggested a simple statement:
    The EDA tool can warn the user if it sees node 0 used in a subcircuit.

  Michael M. said this could be entertained as motion in the next Interconnect
  meeting.

  Discussion to continue in the next Interconnect meeting...
  
- Mike L.: Motion to adjourn.
- Michael M.: Second.
- Arpad: Thank you all for joining.

AR: Arpad to contact Fangyi about whether he wants to be listed as an author on
    the new BIRD to supersede BIRD158.7.

-------------
Next meeting: 17 April 2018 12:00pm PT
-------------

IBIS Interconnect SPICE Wish List:

1) Simulator directives

Other related posts:

  • » [ibis-macro] Minutes from the 10 April ibis-atm meeting - Curtis Clark