[ibis-macro] Minutes from the 11 July ibis-atm meeting

  • From: Curtis Clark <curtis.clark@xxxxxxxxx>
  • To: IBIS-ATM <ibis-macro@xxxxxxxxxxxxx>
  • Date: Fri, 14 Jul 2017 20:13:05 -0400

Minutes from the 11 July ibis-atm meeting are attached.

The following document, which was discussed during the meeting, has been
posted to the ATM work archives.

*DATE* AUTHOR <http://ibis.org/atm_wip/archive-author.html> ORGANIZATION
<http://ibis.org/atm_wip/archive-org.html> TITLE
<http://ibis.org/atm_wip/archive-title.html> FORMATS
11-JUL-2017 Walter Katz SiSoft Electrical Module Description BIRD draft 1 (
zip
<http://ibis.org/atm_wip/archive/20170711/walterkatz/Electrical_Module_Description_BIRD_draft_1.zip>
)(docx
<http://ibis.org/atm_wip/archive/20170711/walterkatz/Electrical%20Module%20Description%20BIRD%20draft%201/BIRD_EMD_1.docx>
)

The following document, which was discussed during the meeting, has been
posted to the Editorial task group work archives.

Title <http://ibis.org/editorial_wip/index-bytitle.htm>FormatsAuthors
<http://ibis.org/editorial_wip/index-byauthor.htm>Organization
<http://ibis.org/editorial_wip/index-bycompany.htm>Date
<http://ibis.org/editorial_wip/index-bydate.htm>
BIRD 161.2 draft 1 .docx
<http://ibis.org/editorial_wip/bird161.2-draft1.docx> Michael Mirmak Intel
Corporation Jul 11 2017
IBIS Macromodel Task Group

Meeting date: 11 July 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
Synopsys:                     Rita Horner
                              Kevin Li
Teraspeed Consulting Group:   Scott McMorrow
Teraspeed Labs:             * Bob Ross
TI:                           Alfred Chong


The meeting was led by Arpad Muranyi.

--------------------------------------------------------------------------------
Opens:
- Arpad: Walter has an EMD proposal to discuss.
- Ambrish: BIRD 190 should not appear under tabled topics.  It was untabled at
           the last meeting.
- Radek: The BIRD 158 agenda item (#8) is obsolete.  I produced a new version,
         and we discussed it last meeting.
- Arpad: I sent a private email to Radek because I have detailed feedback on the
         updated version of BIRD 158.
         
-------------
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.
- Walter: Second.
- Arpad: Anyone opposed? [none]

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

EMD BIRD draft introduction:
- Walter: BIRD draft emailed to ATM June 28.
  - EMD is basically EBD using IBIS ISS subcircuits.
  - Largely copy-and-paste from EBD section of IBIS and from BIRD 189.
  - I think it's relatively straight forward, but needs thorough review.
  - I think it's close to being finished, but I don't think it is for IBIS 7.0,
    so there's no need to rush.
  - There are a couple of issues that we need to think about:
    - EBD only has one connector.  Here there's a possibility of allowing
      multiple connectors.  I think people objected to multiple connectors for
      EBD because it might step on EDA tools' turf.  I've written EMD for a
      single connector.
    - How do we refer to the pins in the EMD [Pin List] itself.  For the pins on
      IBIS [Component]s we use the reference designator (e.g., u1.7), but how do
      we do that for the EMD Pins?  Perhaps .7, or j.7 (adopt j as the reference
      designator for the EMD), or this.7?
    - Rail terminals?
      - We can use reference designators just like signal pins (e.g. u1.8).
      - We will also want to use signal_name like GND.
        - All pins on the module with that signal_name could be shorted.
        - Or say all pins on a specific [Component] or in the [Pin List] with
          that signal_name are shorted together.  There are no bus labels in
          EMD so we don't have that to consider.
- Ken: Do we still have fork, end fork, etc. describing the paths as in EBD?
- Walter: No the ISS subcircuit instance replaces the path descriptions.
- Bob R.: I suggest we introduce this at the Interconnect meeting before
          uploading it.  There might even be more changes in 189.
- Walter: I'm fine with that.  I think we can hold off until 189 is approved.
  - I think this is 98% done, but the last 2% will take time.
- Arpad: When you refer to "only one connector," are you saying traditional EBD
         has a connector and then paths that dead-end at the chips, and that
         you would like to have a through-type arrangement going from one 
         connector to another, as if between the pin and the pad?
- Walter: That's certainly an option we could adopt.  I think this was brought
          up the last time, and people objected to having multiple connectors.
          They thought that would compete with EDA tools.  I think we
          will likely keep it to one connector with a single [Pin List].
- Arpad: One thing we might want to address here is the deliberate deficiency
         we built into BIRD 189, where we disallowed the one-to-many and
         many-to-one mappings for signals.
- Walter: That's not an issue here.  That issue was inside the package.  Here
          you can have one pin go to multiple [Component]s or go to multiple
          pins on a single [Component].
- Bob R.: In BIRD 189 we only have a one-to-one restriction for I/O pins.
  - One-to-many and many-to-one exists for rails.
- Walter: Here in EMD, since we've eliminated the paths, it's just a subcircuit
          with a bunch of terminals.  Lots of the BIRD 189 complications just
          don't exist for EMD.
          
BIRD 191:
- Arpad: What is the reason that we have to do BIRD 191?
  - Up until now, we had "pin" or "die" (pad and buffer meant the same thing).
  - Now with BIRD 189 we separate the buffer from the die-pad.
  - But who is going to make SI simulations at the pad if the buffer terminal
    is separate?
  - If measurements at the buffer are more accurate or more important, do we
    still need the "pad" location?  Do we need both?
- Walter: Yes, compliance testing may be done at the pad.
- Michael M: We need to be very clear and careful with terminology.
  - Meanings of terms have often changed since the original spec was written.
  - What's easiest for various probing?
    - Pin or ball is easiest.  But with faster edge rates the package and on-die
      interconnect are increasingly important, and probing there is less useful.
    - If you have a die without a package, it's easy to probe "after" (Tx sense)
      the on-die interconnect, what we call the die pad.
    - I would argue the hardest thing to probe is the at the buffer.
- Bob R.: If doing it by simulation you'd have access to that point.
  - But the purpose is not to defend the choice of locations.
  - The purpose of this is for completeness and consistency of terminology.
  - Remember that with an interconnect model you can now go directly from the
    buffer to the pin, and you no longer have access to the "pad" location in
    that case.
- Michael M.: What do Vref, Rref, etc., mean?
  - Are they before or after the on-die interconnect, or at the pin?
  - We need to be clear.
- Bob R.: That's why the Si_location is important.  It gives the location where
          they are specified.
- Ambrish/Arpad: This is also related to the A_to_D probing locations in
                 [External Model].
- Arpad: In the current spec, for a receiver model you can put the A_to_D at
         the pad or at the core side of the receiver model.
  - With BIRD 189 interconnect modeling separating pad and buffer, we would
    probably also have to extend the A_to_D location to have a pad option, a
    core side option, and a buffer terminal option.
- Arpad: This is why I'm concerned that we are opening a bigger can of worms.
  - From an SI perspective we are probably more interested in the buffer
    waveforms than the pad waveforms, now that they are separate.  Wouldn't
    it be easier to just make the "die" location now mean the buffer terminal?
    Do we need to go from two choices to three?  Instead of adding a third
    option, just change the meaning of "die" to the buffer terminal.
  - It seems like this will have a lot of ramifications.
- Bob R.: It will be introduced at the next Open Forum meeting.
  - Something needs to be done because we use "die-pad" in BIRD 189.
  - If we went with something like Arpad's suggestion (to change the meaning of
    "die" for Si_location and Timing_location), we would then at least need a
    statement that buffer location and "die" location are considered the same
    even when using an interconnect model.
    
BIRD 158.6:
- Discussion: Arpad noted that he had a significant list of comments based on
  BIRD 158.6 draft 1.  Bob R. noted that the term "pad" was used in the draft
  but not defined in any drawings or figures.  He felt this should be clarified
  to ensure there was no confusion with Interconnect Model "pad" terminology.
  Arpad said he would send his comments to the ATM reflector so everyone could
  review them.  Radek said editorial changes could be made before the next
  meeting, but since we had discussed technical issues at the last meeting he
  preferred not to make any technical changes unless they were discussed during
  a meeting first.
  
BIRD161.2 Supporting Incomplete and Buffer-only [Component] Descriptions:
- Michael M: If BIRD 191 is adopted, I believe BIRD 161 becomes less important
             and can be deferred until after 7.0.
  - First introduced in 2013.
  - Tried to do some of the same things Bob R. is doing in BIRD 191.
    - Address the fact that Timing_location and Si_location needed to be updated
      in light of the new Interconnect rules.
  - BIRD 161 contained some other interconnect related statements that BIRD 189
    has now made obsolete.
  - This new draft removes everything that is addressed in BIRD 189.
  - It now focuses on adding two new Sub-Params to [Component].
    - Scope
      - Allowed values "Complete" or "Partial" (default "Complete").
      - Specifies whether the [Component] describes a complete manufactured
        device, or whether it's a partial description.
      - "Partial" [Component] might only define one [Pin] and use one [Model].
      - Ideally every .ibs file would a have full [Pin] list for an entire
        component.  This rarely happens, and it can be a pain at the beginning
        of development.  IBIS rules prevent me from just giving someone a
        [Model], I'm forced to distribute a [Component].
      - Scope Sub-Param allows the model maker to tell the recipient whether
        the [Component] is meant to define a real component or not.
      - This is a better approach than simply making it legal to not provide
        a [Component] keyword.
    - Pin_reference
      - Related to Scope.
      - Specifies whether [Pin] entries really mean pins, or just the buffer, or
        buffer and on-die interconnect.
      - Allowed values "Pin", "Die", "Buffer" (default "Pin").
      - Pin_reference makes it easier to tell the user what is included.  Many
        keywords ([Pin], [Diff Pin], etc.) by their very name imply Pin,
        which may not be correct for a "Partial" model.
 - At the very least, we need "Scope" in order to support incomplete (e.g., 
   buffer-only) descriptions.
- Bob R.: I think there's a lot of very complicated vetting for this.
  - [Pin], [Diff Pin], [Pin Mapping], etc., there could be a lot of effects.
  - I don't think we should consider it for 7.0.
  - This Scope might be useful purely as information for the user, but I might
    recommend EDA tools simply ignore it.
  - The term "Partial" vs. "Complete" (or incomplete) has other connotations.
- Michael M: I agree with most of what you said, but let's not assume IBIS is
             only for those who sell complete packaged parts.
  - For example, an IP vendor may have a complete description of an IP buffer
    set, and that should be legal to distribute to a package vendor.
- Bob R.: It is legal, you'd just put in a default zeroed out [Pkg], etc.
  - All you need to have a "complete" IBIS model is that every pin in the [Pin]
    list is associated with a model (including rails, NC, etc.).
  - As a practical requirement we said the model "shall" document all the pins.
  - We've reduced that to "should" or "recommend" it should.
  - Language used in this BIRD may not be consistent with Interconnect parlance.
- Arpad: I reviewed it too.
  - I do see the areas that could be removed from it, and I see the new text.
  - We will need to review its verbiage very carefully, because after the
    removal of some of the old text the verbiage becomes inconsistent and/or
    confusing.
- Michael M: Agreed.
- Mike L.: Most of the models I see are buffer-only models.
  - There are many of them out in the world.
  - I do see some benefits from putting models in one category or another.
  - EDA tools might be able to deal with them differently or offer only the
    appropriate ones to the user.
  - I do see an issue with terminology.
  - There's a continuum.  One file might only have one buffer and everything
    else is invented overhead.  The other extreme would be a fully complete
    [Component] for an actual part.
  - What's desired here is a binary flag to indicate when you have "buffers
    only", but use of "Complete" or "Partial" implies something else.
  - Maybe we could change the allowed values to "buffers-only" vs. something
    else.
- Bob R.: As an example of Mike's point, it's real to offer an ASIC library
          of various buffer models all packaged into one big [Pin] list, and
          the intent is just to provide buffer models.
- Ken/Mike L. - FPGA models do that all the time.
- Michael M: Motion to table BIRD 161.
- Bob R.: Second. [no one opposed]

BIRD 190:
- Ambrish: I just wanted to revisit this quickly.
  - I'm hoping everyone will agree that it's only a warning for the time domain
    redriver flow.
  - Someone who comes across the repeater section may not look back to the
    warning in the single channel flow.
  - Let's keep the flows simple.
- Arpad: Is this scheduled for a vote in the Open Forum?
- Walter: It is eligibile, but not scheduled.
  - The repeater flow references doing things according to the normal single
    channel flow.  That section already has the warning words Ambrish wants.
  - Passing this would reaffirm what I believe we know is an incorrect flow.
- Arpad: Do we need more discussion here, or do we go to the Open Forum?
- Ambrish: I would want to get consensus here in ATM before I would put it up
           for a vote in the Open Forum.
  - We haven't really specifically voted on this in the ATM strictly on the
    merits of this BIRD.  We had a straw poll that may have been under the
    assumption that this affects the statistical flow too.
- Walter: Let's have a discussion next week, and then we can make a
          recommendation to the Open Forum.
          
- Ambrish: Motion to adjourn.
- Mike L.: Second. 
- Arpad: Thank you all for joining.

AR: Arpad to email his BIRD 158.6 draft 1 comments to the ATM reflector.

-------------
Next meeting: 18 July 2017 12:00pm PT
-------------

IBIS Interconnect SPICE Wish List:

1) Simulator directives

Other related posts:

  • » [ibis-macro] Minutes from the 11 July ibis-atm meeting - Curtis Clark