[ibis-macro] Minutes from the 20 March ibis-atm meeting

  • From: Curtis Clark <curtis.clark@xxxxxxxxx>
  • To: IBIS-ATM <ibis-macro@xxxxxxxxxxxxx>
  • Date: Tue, 27 Mar 2018 01:18:04 -0400

Minutes from the 20 March ibis-atm meeting are attached.
IBIS Macromodel Task Group

Meeting date: 20 March 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 second draft of the new BIRD to supersede BIRD158.7.
  - Done.
  
--------------------------
Call for patent disclosure:

- None.

-------------------------
Review of Meeting Minutes:
- Discussion: Ambrish noted that he had called in to the previous meeting a few
  minutes late, but he was not shown on the attendance list in the meeting
  minutes.  Curtis said this was on oversight on his part, and that he would
  correct it.
- Arpad: Does anyone have any comments or corrections? [none]
- Ambrish: Motion to approve the minutes.
- Bob: Second.
- Arpad: Anyone opposed? [none]

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

BIRD189 and BIRD158 related issues:
- Walter: At the previous Interconnect meeting some of us took ARs to explain
          what they think should be the local reference node.
  - Randy has since sent an email stating that he does ground based modeling all
    the time (even for power aware).
- Arpad: I had an AR for this too, and expect to have something ready for the
         Interconnect meeting tomorrow.
- Walter: [sharing "Is A_gnd Model or Component" email]
  - 6 Pin example
    - DQ   (I/O)
    - CMD  (In)
    - VSS  (GND)
    - VSSQ (GND)
    - VDD  (POWER)
    - VDDQ (POWER)
  - Mimics Micron memory chips.
  - I assume VSS and VSSQ are isolated in the package and in the chip.
  - Same for VDD and VDDQ.
  - I assume on the board the VDDs and VSSs may be tied together.
- Randy: We combine VSS and VSSQ on the die, while they may be separated in the
         package in many cases.
  - VDD and VDDQ are kept separate.
- Walter: Okay, that affects some of my results.
  - [continuing]
  - [Pin Mapping] shows:
    - VSSQ and VDDQ as the pulldown and pullup references for DQ.
    - VSS and VDD as the pulldown and pullup references for CMD.
  - Example has 4 [Interconnect Model Groups].
    - Each group uses the same [Interconnect Model Set] Power for power pins.
    - Each group then uses its own additional set for the I/O.
    - Models show subcircuit pseudo-code in comments for reference.
  - First Set is Power (4 Pins)
    - 8 Terminals - 4 Pin side, 4 on the buffer side.
      - 0.1 Ohm resistors for each path.  Simple, no W-elements, etc.
    - Assuming all VDD pins are shorted on the Pin side and buffer side.
    - Assuming all VDDQ pins are shorted on the Pin side and buffer side.
    - Similarly for VSS and VSSQ.
    - Board implementation decides how they are powered, so I'm not assuming VSS
      and VSSQ are the same, or VDD and VDDQ are the same, on the Pin side.
    - According to what Randy said, VDD and VDDQ are not shorted on the die, but
      VSS and VSSQ likely are.
    - I'm assuming they're separated on the die for this discussion.
  - Next Set is Set1
    - Contains 1 Model named "all_signal"
    - 6 Terminals (2 Signal Pins on pin and die side, 2 Separate references)
    - VSS and VSSQ passed in as references.
    - W-line for Pin1 (DQ) references VSSQ.
    - W-line for Pin2 (CMD) references VSS.
    - This example should satisfy the people who say their simulator doesn't
      have a node 0.  There is no use of "node 0" or A_gnd.
  - Next Set is Set2
    - This breaks it up into two separate models, one for DQ and one for CMD.
    - This is functionally equivalent to Set1.
  - Next Set is Set3
    - This is the two-model approach, like Set2.
    - But here we use A_gnd as the reference terminal for each model.
    - EDA tool could set A_gnd to node 0 and do ground based power aware
      simulations.
    - Tool could also say, "I know this is Pin1, and I can go over to the [Pin
      Mapping] and figure out that VSSQ is the pulldown_ref of Pin1".  So the
      tool could decide to use VSSQ instead of node 0 if it wanted to.
  - Next Set is Set4.
    - This is a single model approach, like Set1.
    - But I'm just assigning a single A_gnd.
    - If we say A_gnd is a local ground, then I have to go through and look at
      the Pins to figure out the reference.
    - But Pin1 references VSSQ, and Pin2 references VSS.  So now the tool
      doesn't know which local reference to use (since both Pins are in this
      same Model), so it would have to default to node 0.
    - If we say A_gnd is just a shortcut to node 0, then we are okay.
    - But if we say it's a local reference, we run into the trouble with two
      possible local references in this example.
- Discussion: Arpad noted that Set4 was a perfect example to illustrate the
  question of whether A_gnd should be considered a local reference drawn from
  the [Model] keyword or from the [Component] keyword.  He noted that if the two
  Models (Pin1 and Pin2) have their own independent local references (VSS and
  VSSQ) then you wouldn't know how to connect A_gnd.  However, if A_gnd were
  defined as a local [Component] reference, then all [Model]s would have the
  same reference.  Walter countered that at the [Component] level for this
  example we still have two potential references, the Pin providing VSS and the
  Pin providing VSSQ.  Walter noted that he had recently looked at parts that
  had a large number (more than 15) of reference ("ground") Pins.  Walter
  suggested that even if all of those (e.g. VSS, VSSQ, etc.) were tied together
  on the board, the package modeling would likely keep VSS and VSSQ separate
  and have all the DQ lines relative to VSSQ and the CMD lines relative to
  VSS.  Is your reference how you're measuring the voltage, or where the current
  return path is?  If A_gnd is a local reference, not node 0, then you have to
  answer those questions.  Arpad agreed, but wanted to take up the question by
  looking at a more interesting example for the "Power" Set.  
  
  Arpad noted that the Power set used simple .1 Ohm resistors for the current
  paths (VDD, VDDQ, VSS, VSSQ).  Arpad asked what would happen if you replaced
  the simple resistors for VSS and VSSQ with two single-conductor W-elements.
  So, the signal conductor of the W-element connects the pin and buffer sides
  of the VSS signal (or VSSQ signal).  Those W-elements would have reference
  terminals, and what would they be?  Bob said one solution might be to just
  use the L_gnd and R_gnd in the W-element for the through path, and utilize
  two separate references on each end of the W-element.  He also noted that
  you could use an independent isolated reference and model the full path
  of the VSS line in a W-element referenced to independent reference.
  
  Walter said it's done today one of two ways.  You can let VSS and VSSQ float
  relative to node 0.  Alternatively, what most everyone does today is to
  include the loss on the ground side path in the power side.  This gives you
  the proper voltage drop of the rail voltage, and allows all the "grounds" to
  be tied to node 0 (ground based power aware modeling).  That's the way most
  tools generate power aware models.  If you're not doing power aware it's all
  academic.  Some people object to the ground based power aware modeling, and
  my suggestion to them is that you then have to be careful to ensure that every
  model you're using is created in a way that avoids use of node 0.  But most
  models are created based on ground based modeling.
  
  Bob noted that the syntax would support separate references, one for Pin1 and
  one for Pin2 (as illustrated by Set1).  Radek reiterated that if you put "node
  0" in the subcircuit it has a global meaning.  If you have a global node it
  must also be a node available externally, not just hidden inside the sub-
  circuit.  We have to be clear that if node 0 is part of the subcircuit then it
  is part of the set of nodes that span the buffer behavior.  If we don't say
  anything about that, then the EDA tool or end user could connect things in
  such a way that they get inconsistent results depending on what is connected
  to node 0.  Radek noted that the example Randy provided (in reply to the
  "Question to Randy and MM" email), was a very good example of this.  It has
  capacitors to Ext_Gnd_Ref node, in addition to VSS, VSSQ, etc.  So it is
  a very clear example that the Ext_Gnd_Ref node must be part of the overall
  model.  Bob noted that Ext_Gnd_Ref is not node 0, but is the reference for
  all the capacitors.  It could be assigned 0.0V relative to node 0.
  Radek agreed.  Radek noted that if you put A_gnd inside the subcircuit it
  is hidden internally and no one knows about it.  But, if as shown in Walter's
  examples (Set3 and Set4), it is specified as one of the terminals of the
  model, then it must be one of the nodes that is exposed to the external world.
  Just hooking that single A_gnd to one of the model's references would be
  wrong in Set4.
  
  Walter noted that for the BIRD158 case, since a Ts4file is hooked up to a
  specific model, A_gnd can be considered a local reference unambiguously.
  He suggested BIRD158 needed no changes, but he would be okay with adding
  A_gnd as a clarification, though it was an academic exercise.  Walter also
  noted that his Set3 could use a model centric local reference, while
  Set4 wouldn't work with a model centric or component centric reference.
  
  Arpad revisited his questions/examples with a Thevenin equivalent circuit
  for the S-parameter block.  He asked what the reference side (negative
  terminal) of the voltage source would be connected to.  Walter said it didn't
  matter because BIRD158 is all differential.  Arpad noted that the BIRD158 Tx
  figure explicitly shows the reference terminal as the center of the two
  voltage sources, each providing half the swing.  He noted that it could simply
  have been shown as a single differential voltage source if we didn't care
  about common mode.  Walter agreed that this could have been shown as a single
  differential voltage source.  Radek, however, noted that a differential port
  needs 3 terminals, and that is what is shown in the BIRD158 Tx figure.  You
  really need the common mode pin for a differential port.
  
  Arpad set aside the Thevenin example.  He went back to the basic BIRD158
  Ts4file model.  He noted that it had 4 terminals for the 2 signal lines and
  a fifth reference terminal.  If we had a package model with a W-element
  line for the conductor carrying VSS between pin and pad, and its additional
  reference terminal, how would that W-element be connected to the S-parameter
  block of the BIRD158 model?  Walter said it didn't matter because it's all
  differential.
  
  Arpad noted that he was asking these questions because they arose when he
  attempted to craft the language of the BIRD158 replacement BIRD with respect
  to BIRD189.  (Note: Arpad later created figures to illustrate all of the
  examples in Walter's Model Groups, and the discussions continued in the
  Interconnect meeting on March 21st.)
  
- Curtis: Motion to adjourn.
- Walter: Second.
- Arpad: Thank you all for joining.

AR: Arpad to prepare a new draft of the BIRD to supersede BIRD158.7.

-------------
Next meeting: 27 March 2018 12:00pm PT
-------------

IBIS Interconnect SPICE Wish List:

1) Simulator directives

Other related posts:

  • » [ibis-macro] Minutes from the 20 March ibis-atm meeting - Curtis Clark