[ibis-macro] Minutes from the 24 May ibis-atm meeting

  • From: Curtis Clark <curtis.clark@xxxxxxxxx>
  • To: ibis-macro@xxxxxxxxxxxxx
  • Date: Fri, 27 May 2016 13:08:36 -0400

Minutes from the 24 May ibis-atm meeting are attached.

The following document, which was discussed during the meeting, has been
posted to the work archive.
*DATE* AUTHOR <http://ibis.org/macromodel_wip/archive-author.html>
ORGANIZATION <http://ibis.org/macromodel_wip/archive-org.html> TITLE
<http://ibis.org/macromodel_wip/archive-title.html> FORMATS
24-MAY-2016 Fangyi Rao Keysight Technologies AMI Simulation Flow Round 3 v5
(zip
<http://ibis.org/macromodel_wip/archive/20160524/fangyirao/AMI_Simulation_Flow_Round_3_v5.zip>
)(pptx
<http://ibis.org/macromodel_wip/archive/20160524/fangyirao/AMI%20Simulation%20Flow%20Round%203%20v5/AMI_flow_round3_v5.pptx>
)
IBIS Macromodel Task Group

Meeting date: 24 May 2016

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
Cisco:                        Seungyong (Brian) Baek
eASIC:                        David Banas
                              Marc Kowalski
Ericsson:                     Anders Ekholm
GlobalFoundries:              Steve Parker
IBM                         * Luis Armenta
Intel:                      * Michael Mirmak
Keysight Technologies:      * Fangyi Rao
                              Radek Biernacki
                              Ming Yan
Maxim Integrated Products:    Hassan Rafat
Mentor Graphics:              John Angulo
                            * Arpad Muranyi
Micron Technology:          * Randy Wolff
                              Justin Butterfield
QLogic Corp.:                 James Zhou
                              Andy Joy
SiSoft:                     * Walter Katz
                              Todd Westerhoff
                            * Mike LaBonte
Synopsys:                     Rita Horner
Teraspeed Consulting Group:   Scott McMorrow
Teraspeed Labs:             * Bob Ross
TI:                           Alfred Chong


The meeting was led by Arpad Muranyi.

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

- Luis had joined the ATM meetings previously when he was with ANSYS.  Arpad
  asked him to briefly reintroduce himself in his new role with IBM.  Luis said
  he is working with the signal integrity team for the OpenPOWER Consortium, and
  that they will be producing IBIS-AMI models for their customers. 

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

- Ambrish to send the latest BIRD 147 draft to Bob and Walter, as requested.
  - Done.

- Ambrish to check for a collaborator's feedback on his nearly ready new
  version of the Backchannel proposal.
  - In progress.

--------------------------
Call for patent disclosure:

- None.

-------------------------
Review of Meeting Minutes:

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

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

[Pin Reference] BIRD Draft:
- Arpad: We did discuss this last week in Walter's absence.
  - Were you able to follow that discussion in the minutes, Walter?
- Walter: Yes, I kept up with the minutes.
  - My response to last week's discussion is that there are two distinct issues.
    - 1. There's just a shift in voltage for a device under test.
      - What's connected to the gc_ref is not 0V, but some non-zero voltage
        relative to the simulator's node 0.
      - How do you adjust the value of the voltage at the I/O pad in order to
        compare that correctly with thresholds in the IBIS file (e.g. Vinl)?
      - This would be the oft discussed case of VSS=1000V and VDD=1005V and
        the buffer should still work fine and the threshold should be 1002.5V.
    - 2. A device under test has 0V for its [GND Clamp Reference] and 5V for its
         [POWER Clamp Reference], but at simulation time the device in action
         sees a 6V difference between pc_ref and gc_ref.  How should the
         thresholds be adjusted in that scenario?
      - [Receiver Thresholds] offered one way to deal with that.
      - Bob added a bunch of stuff to draft 3 of the BIRD to deal with this
        second issue, but it's a separate issue.
      - I think the way to deal with this would be to add a "technology"
        keyword with values like CMOS, TTL, ECL, PECL, etc.
        - We could add rules for each technology that specify how thresholds
          change.
- Arpad: I think the original purpose of this BIRD draft was to help the Friday
         editorial meetings with their "ground" problems.
  - I understand this second issue seems like mission creep.
  - I would suggest a minimalist approach.  Let us only cover what is needed for
    the editorial task group, but do it in such a way that we can expand upon it
    at a later time.
- Walter: I don't think editorial is waiting on it.
  - I think they are expecting something like this [Pin Reference] BIRD to deal
    with these issues.
  - I would like to defer to the editorial group and see what they need.
- Mike L.: This is a new keyword.
  - It would not have wide spread impact.
  - It won't hurt the editorial group if it doesn't come along until later.
- Arpad: If the editorial work has this BIRD as a dependency, can they move
         forward?
  - What if this BIRD fails to be approved later?
- Bob: I have a slightly different view than was presented here.
  - This group might be the better group to resolve some technical issues we
    haven't really resolved.
  - But I don't think this is holding up editorial.
- Walter: Motion to table this BIRD here.
- Dan: Second.
- Arpad: Anyone opposed? [none]

SPI 2016 report: [Walter asked to talk about SPI briefly]
- Walter:
  - About 110 registered participants.
  - Mostly from Europe, perhaps 15 or 20 from Asia.
  - Several interesting papers related to IBIS I/O methodology.
  - Interesting and different approaches to our current I/V and v(t) Models.
    - One with v(t) tables but using 3 columns per corner.
    - One that was not table driven at all.
  - Some were admittedly science projects not ready for prime time.
  - My response to everyone was that they were all interesting approaches, but
    it is going to be very hard to get something through IBIS if EDA vendors
    will have to adopt something different than the existing K(t) methodology.
  - My suggestion to them was that rather than come up with a different table
    driven scheme where the EDA tools have to figure it out, perhaps we should
    come up with a .dll interface with the [External Model].  The .dll could
    even read tables, but I was just imagining how tough it would be to get
    some of these new methodologies through IBIS.
  - I also had conversations with a number of people on package models and their
    particular methods for doing power integrity.
  - There was certainly no consensus on one right way to do it.
  - I did come away convinced that the approach we are taking with the
    interconnect task group would satisfy the needs of all of their different
    power integrity methodologies.
- Bob: Could you elaborate on the different power integrity approaches?
- Walter: It's not uncommon that they would have separate power and data models.
  - The most complicated models lumped all of the grounds at the IC together
    and all the Pins together.  So you could not have nodes per pin, it was
    nodes per each of what we call signal_name.
  - Some used SPICE models for the power and SPICE models for the interconnect
    and a totally different methodology for coupling the two.
  - Some approaches said, "it's just an impedance problem, you find out the
    impedance of the board and that's the impedance requirement for the
    package."
  - Some simulations took days.  Some used noise budgets.  There were lots of
    research projects.
- Bob: Many of these are PhD students presenting, and we've kept in touch with
       many of them over many years.
- Walter: Some given by PhD students, some by professors, one by Intel.
  - It was varied, not all academic.
  - Keysight gave a nice boot camp on power and signal integrity.
  - All the papers are published and one can read them.
- Arpad: Walter, you mentioned something about Touchstone v2.0 in one of your
         email reports.  Can you elaborate?
- Walter: I am on the IEEE SA - P370 group, which is dealing with standards for
          s-parameter data measurements.
  - Several people on that committee happened to be at SPI.
  - When I mentioned Touchstone v2.0 I got some sour responses from people.
  - I suggested that we document some of the things they were doing with respect
    to quality of s-parameter data and gather some of them into an enhanced
    Touchstone v2.0, and they said, "Don't even bother, no one wants to touch
    Touchstone v2.0 with a ten-foot pole."
  - They said that "no tools read it and no tools write it."  Obviously "no"
    is an overstatement, but there are so many internal, non-commercial tools
    people use that parse Touchstone files but don't support v2.0 that it is
    just unacceptable to the industry.
  - The only thing Touchstone v2.0 has that addressed a real need for people
    was per port impedance.  If that was all that had been added it might have
    been adopted more widely.
  - But something as simple as removing the requirement for .sNp as the file
    extension was a deal breaker because so many tools relied on it.
  - Feedback I got was that they would like IBIS to do something, but don't
    change the Touchstone format.  Leave Touchstone v1.0 as it is.  Perhaps
    add one change for impedance per port.  Perhaps define a side file that
    will define the near end, far end, and differential pairs without
    complicating the Touchstone file.
  - I have heard about, but not personally seen, the existence of one
    Touchstone v2.0 file.
- Arpad: If Touchstone v2.0 does more than they want, why can't they just use
         part of it?
- Walter: It's the whole structure.  To use it at all you need to add in a bunch
          of new parts that break existing readers.

C_Comp Improvements:
- Discussion: Randy said he had recently reviewed the most recent draft, which
  was almost a year old.  He said he needed to make some updates based on new
  decisions that had been made for the interconnect BIRD.  He said he would
  update it and present it to the group at a future meeting.

- New Redriver Flow:
- Fangyi: [sharing his updated "AMI Simulation Flow Round 3" version 5]
  - I've updated the parameters according to the discussion we had in the
    meeting two weeks ago.
  - [Slide 12 - New Reserved Parameters]
    - Last time we talked about changing back to a two parameter approach
      because people didn't like the bi-directional parameter approach.
    - Two parameters:
      - Support_Proposed_Flow
        - Rx parameter, Info, Boolean, default=false
        - This parameter tells the simulator whether the Rx model supports the
          proposed flow.
      - Use_Proposed_Flow
        - Rx parameter, In, Boolean, default=false.
        - This parameter tells the model if the EDA tool is using the 6.1
          flow or the new proposed flow.
    - These parameter names are not finalized.
  - [Slide 13 - contains a truth table for Parameter settings]
    - If Support_Proposed_Flow is false:
      - Tool and model must use 6.1 flow.
      - Tool cannot set Use_Proposed_Flow to true (illegal).
    - If Support_Proposed_Flow is true:
      - Simulator can still set Use_Proposed_Flow to false to use the old 6.1
        flow.
      - Simulator can set Use_Proposed_Flow to true and then the tool and model
        will use the new proposed flow.
- Discussion: Fangyi asked the group if we should require a model that supports
  the new flow to also support the old flow.  Mike suggested that the question
  amounted to weighing the work imposed on the model maker for mandatory support
  of the old flow vs. the potential reputation issues for IBIS-AMI if we allowed
  a new class of models (new proposed flow only) that simply wouldn't work with
  any older tools.  Walter said that he was fine with going to a two parameter
  approach, but that we should require models to support the old flow.  He said
  that it should be easy for a model maker supporting the new flow to also
  support the old flow.  Fangyi agreed that it should not be a big deal for a
  model that will support the new flow to also support the old flow.  Arpad
  said that if that were true then we should make support for the old flow
  mandatory.  No one in the group disagreed with the decision to keep support
  for the old flow mandatory.  Arpad did raise the question of how long the spec
  would make support for the old flow mandatory.  Curtis said that since we have
  the AMI_version parameter, we could wait until a future revision and decide to
  deprecate it then.  Fangyi agreed.  Walter said he thought we probably never
  would or should deprecate it.  Bob suggested that we should come up with 
better
  names than "new" (proposed) and "old" (6.1) flow.  Mike agreed that the sooner
  we came up with the final names the better.  Mike noted that we had previously
  discussed this in the context of DFE, and he had wondered if we could come up
  with a more general category.  He suggested we might use terms like a "one
  impulse response" flow and a "two impulse response" flow.
- Michael M.: Motion to adjourn.
- Curtis: Second.
- Arpad: Thank you all for joining.

-------------
Next meeting: 31 May 2016 12:00pm PT
-------------

IBIS Interconnect SPICE Wish List:

1) Simulator directives

Other related posts: