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

  • From: Curtis Clark <curtis.clark@xxxxxxxxx>
  • To: IBIS-ATM <ibis-macro@xxxxxxxxxxxxx>
  • Date: Mon, 12 Mar 2018 16:19:42 -0400

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

Meeting date: 06 March 2018

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.


- None.

Review of ARs:

- None.
Call for patent disclosure:

- None.

Review of Meeting Minutes:

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

New Discussion:

BIRD189 and BIRD158 related issues:
- Arpad: At the Interconnect meeting they wanted us to review BIRD158 in the
         context of BIRD189.  Radek had raised some issues.
- Bob: Should we go into the "ground" discussion?
- Arpad: Anything strictly BIRD189 related should be handled in the Interconnect
         meeting, but the ground issue is part of the BIRD158 vs BIRD189
         issue, so we could discuss it here.
- Radek: [having Arpad share his 'BIRD158 and BIRD189 Referencing Problems'
          slides from the ATM meeting on February 20th, 2018]
 - [BIRD158 figure showing the entire channel topology]
 - Diagram shows the channel, package, etc., and the 4 port S-parameter data
   provided by the Ts4File.
 - This is an AMI specific configuration.
 - The different pieces can be characterized with Touchstone files.
 - Figure shows a common reference for all of them, as we have discussed.
 - The real point is that the package should also be represented as a 4 port,
   and all of the terminals shown here are the I/O terminals, and this common
   reference node for all of them is the A_gnd (the local ground).
 - But a BIRD189 package model may not be created this way.  It may also include
   other terminals related to the rails.  We need to address that.
 - What we need in BIRD158 is the 4 port structures that span the I/O terminals
   and the common reference we will term A_gnd.
 - Interconnect model maker may provide exactly that, a 4 Port Interconnect
   model that spans pairs of differential I/O pins with A_gnd as the reference.
 - IBIS-ISS can be used as well, but the point is that A_gnd should still be
   there as the reference for the channel.
 - The problem is if the interconnect model provides other terminals for the
   rails, then we don't have a solution for that yet.  My solution would be to
   tie one of the rails to A_gnd for this BIRD158 AMI application.

- Walter: [sharing a private email related to common references]
  - There are three types of simulations:
    - 1. Not Power Aware
      - All rail voltages are DC voltages.
      - All reference nodes are connected to a "ground" node (i.e. a rail
        voltage with DC level 0V relative to a simulator global reference, e.g.
        node 0) or a single simulation reference node.
    - 2. Ground Based Power Aware
      -  The voltage rails that are not "0" can vary with time and float.
      -  All "ground" rail nodes are connected to a "ground" node (i.e. a rail
        voltage with DC level 0V relative to a simulator global reference, e.g.
        node 0) or a single simulation reference node.  (e.g. tie all your VCC
        rails to node 0).
      - All reference nodes are connected to a "ground" node (i.e. a rail
        voltage with DC level 0V relative to a simulator global reference, e.g.
        node 0) or a single simulation reference node.
    - 3. Power Aware, where local "ground" nodes can float relative to a
         simulator or simulation reference node.
      - This requires an understanding by both the model maker and the tool he
        is using to generate interconnect models that correctly reference
        appropriate rail terminals at the buffer/die and at the pin.
      - BIRD189 allows the model maker and tool to create models with reference
        terminals that satisfy this requirement.
  - The model maker should document if all of the Interconnect Models in all of
    the Interconnect Model Sets in an Interconnect Model Group support case 3.
  - We may choose to add a keyword to the [Interconnect Model Group] that
    indicates that the Group is fully power aware.
  - Note that a fully power aware model can still be used in scenarios 1 and 2
    by tying the references to 0V.
  - BIRD158 simulations are for AMI.  They are LTI.  They are not power aware
    when generating step responses for AMI simulations.  It doesn't matter what
    the user did connecting reference nodes.  The EDA tool is going to do a non-
    power aware simulation and tie all those reference nodes to A_gnd or node 0.
  - We may want to write this up more carefully along these lines, but there is
    nothing wrong with the existing format we have.
  - It just means that when someone is doing full power aware simulations that
    support the local ground node floating relative to node 0 they have to do it
  - I think text along these lines (3 types of simulation) could be added to the
    justification for the BIRD, or the BIRD text itself, and that could be the
    end of this discussion on A_gnd and power aware simulations.
- Bob: I largely support what Walter has said.
  - I would add a clarification statement that for BIRD158 the full capability
    of BIRD189 is not supported nor relevant.
- Walter: I don't agree with that statement.  A fully power aware BIRD189 model
          is supported properly by BIRD158.  You just recognize that you're not
          doing a power aware simulation with BIRD158, and tie the rail 
          voltages to DC levels.
- Radek: That's exactly what I've been asking for.  We have an Interconnect 
         Model Group, and we should spell out for the EDA tool and the user
         exactly how things should be handled for the application of BIRD158.
         We agree, but we have to spell it out.

- Arpad: We are converging on a solution.
  - Which BIRD should be modified to add this text?
- Radek: I think BIRD158 is okay already.
  - In BIRD189 we may want to add clarification on how models are used in AMI or
    non-power aware simulations.
- Arpad: [referring to the "triangle ground symbol" Note that appears 3 times
          in BIRD158 (at the bottom of his full channel topology slide)]
  - Should we change the sentence:
         "This node would typically be the global ground, such as node 0 in
    and replace the node 0 reference with the A_gnd we use in BIRD189?
  - Should we remove the "typically", which allows the EDA tool to do whatever
    it wants?  Should we mandate the use of A_gnd?
- Radek: We can't mandate the use of A_gnd for the channel block.  That
         connection is made by the user or tool.  The best solution is probably
         to remove that sentence entirely.
  - We already say (previous sentence) that they're all the same node.  When
    we have BIRD158 used in conjunction with BIRD189, BIRD189 will say that node
    is A_gnd.
- Discussion: Arpad noted that with the current understanding of A_gnd as a
  "local ground", it was local to a given component.  Therefore, a Tx on one
  end and an Rx on the other might have A_gnd connected to different nodes.
  He therefore preferred to have BIRD158 state that the reference node for the
  TS4 file blocks is A_gnd, the local ground.  Bob noted that BIRD158 did not
  have anything in its syntax to specify the reference node.  Arpad noted that
  in the context of the recently added warning in BIRD189 strongly suggesting
  the use of A_gnd as the reference for the package model, a similar statement
  in BIRD158 that A_gnd would be the reference for the Ts4file Touchstone block
  made sense.  Ambrish expressed concern for mixing the BIRD158 and BIRD189
  warnings in case a model maker only wanted to read the BIRD158 section.  He
  suggested BIRD158 might just need an additional warning that BIRD158
  simulations are not power aware.  Walter noted that BIRD158, since it is an
  impulse response based simulation, only requires the references to be
  connected to DC voltage levels.  Radek suggested we might state that all
  ground references are assumed shorted to A_gnd in the absence of any more
  specific information.  Arpad proposed a combination of Ambrish's warning with
  Radek and Walter's ideas, and said that we might state that if BIRD158 is used
  with a BIRD189 model, then the model maker should probably use A_gnd as the
  reference for the BIRD189 model.
  Arpad said he would take the AR to make this BIRD189 related cleanup
  to BIRD158.  Since BIRD158 (BIRD158.7) is already approved, he asked what the
  group thought was the best way to do it.  Bob disliked the idea of re-opening
  BIRD158.  Arpad agreed to create a new BIRD that starts with the BIRD158.7
  text and indicates the required changes.
  Mike L. asked why BIRD158 even showed the package model and channel in the
  figure.  Arpad said it was to show common referencing for the entire channel.
  Arpad revisited slides 3 and 4 from his Feb 20th presentation.  He noted
  that these illustrated the same thing as the full channel figure in BIRD158.
  He again discussed the possibility of an N+2 channel model, and he suggested
  that the current BIRD158 assumption that all the reference nodes are the same
  was not necessary.  Walter noted that we could dramatically complicate the
  language of BIRD158 with additional changes, but that in practice we can
  safely assume that the reference nodes are tied together for BIRD158
  simulations.  He said when people build SERDES channels they are extremely
  careful to make sure all the references throughout the channel are well
  connected.  Ambrish noted that he disagreed with Walter's statement.
BIRD189: Rail Rule Relaxation:
- Discussion: Arpad shared some figures he had created previously for a
  different discussion to illustrate the suggestions in Bob's Rail Rule
  Relaxation proposals.  Walter noted that he thought the rule relaxation was
  unnecessary, and that we had demonstrated that decoupling cap modeling could
  be handled to Randy's satisfaction with the current BIRD189.  Further
  discussion was deferred to the next Interconnect meeting.

- Ambrish: Motion to adjourn.
- Walter: Second.
- Arpad: Thank you all for joining.

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

Next meeting: 13 March 2018 12:00pm PT

IBIS Interconnect SPICE Wish List:

1) Simulator directives

Other related posts:

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