[ibis-macro] Minutes from the 31 October ibis-atm meeting

  • From: Curtis Clark <curtis.clark@xxxxxxxxx>
  • To: IBIS-ATM <ibis-macro@xxxxxxxxxxxxx>
  • Date: Mon, 6 Nov 2017 14:42:21 -0500

Minutes from the 31 October ibis-atm meeting are attached.
IBIS Macromodel Task Group

Meeting date: 31 October 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.  Curtis Clark took the minutes.

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

- None.

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

- Radek to produce a new draft of BIRD189.5 containing his two additional
  options for Unused_port_termination(s).

  - Done. (BIRD189.5, draft10_v2)
  
--------------------------
Call for patent disclosure:

- None.

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

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

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

BIRD189 - Unused port termination:
- Arpad: [sharing Radek's BIRD189.5 draft10_v2]
- Radek: This version is not editorially complete and correct.
  - I had time to add the major points (two new settings).
  - Tables, etc., need to be updated.
  - We had follow up emails from:
    - Bob, touching on how or what a model maker may or may not know.
      - My reply was that if the model maker doesn't know then we should not
        allow there to be any unused port terminations at all.
      - Still more follow up discussion to be had...
    - Arpad, asking whether or not we need "Open" (is it redundant?).
      - My reply is that Open-is-Open, we don't have to tell the tool how to do
        open or spell out a specific value.
      - I prefer that "Open" stay as an option.
  - This section introduces two Subparameters:
    - Unused_port_termination_directive
      - Previously I had used "mode" instead of "directive", the name may
        change.
      - This is the one with four choices.
      - Required only if there are unused port terminations.
    - Unused_port_terminations
      - Required and allowed if you choose the second or third options for the
        directive (Common_resistance, or Per_port_resistances).
      - Illegal otherwise.
      - Contains the value or values.
      - Spells out the rules.
      - I think we should explicitly spell out that the N+1 terminal (reference
        terminal) must not be unterminated.
- Walter: I'm fine with this.
  - I noted that there was some inconsistency in the naming of the two
    parameters in various places (UnusedPort_terminations - probably should be
    Unused_port_terminations to be consistent).
- Bob: My fundamental question has never been answered.
  - How does the model maker determine these values as different than the
    reference impedance?
  - The model maker does not know why you would choose anything other than the
    reference impedance.
  - In your example in the draft, how would the specified value of 48.5 Ohms
    have been determined?
- Radek: How is the reference impedance of 50 Ohms determined?
- Bob: That's the reference impedance.
- Radek: How is that determined as the actual termination?
  - The reference impedance is coming from the actual measurement, or it can be
    superficial.  It was very common with simulators in the old days that
    regardless of the impedance of the line all the data was recalculated
    to 50 Ohms.
  - This is a mathematical concept that is needed.  If you do have termination
    that is equal to the reference impedance, then you have certain properties
    you can take advantage of, reflected wave is zero, etc.
  - But only if the termination connected to that port is equal to the reference
    impedance.  Otherwise, for any other impedance, things will be different.
  - If the model maker does not know how to terminate these, then he should
    never provide this data that would be ambiguous.
- Bob: When you say reference impedance of the line, is that the external
       connection to the line, or is 48.5 the reference impedance of the
       unused port.
- Radek: On the measurement, it could be the fixture impedance, which is outside
         the device under test.
- Bob: You've extracted that port data based on that fixture impedance of 48.5,
       and therefore embedded r=48.5 for that port in the Touchstone file.
- Radek: Yes, or it could be a calculated value.
  - The N port parameters describe only the internal parts of the N-port device.
  - Unused_port_terminations is saying what is outside of those ports.
  - The first answer, if the port is really unused, for example a connector
    where you don't use all of the pins, is still to have it Open.
  - That's why I say Open should be the default, it's the prevailing case.
  - Only the model maker knows.
- Bob: I'm trying to understand if that 48.5 comes from extracting the
       S-parameters.  If so, then that should be documented as that port's
       impedance, which Touchstone 2.0 allows - per port resistance.
  - But if that port was extracted with common 50 Ohm connectors, fixtures,
    VNA, etc., then I don't understand 48.5 Ohms.
- Radek: I don't understand it either.  This is just an example where the model
         maker may know that 48.5 Ohms represents what is at that port.
  - It's not for me to know that.
  - It's for the model maker to tell us what to do with that data.
- Bob: If the model maker knows it's 48.5, then that value should be embedded in
       the S-parameters, and the Reference option should work fine and get the
       value from the Touchstone file.
  - The model maker doesn't know what particular design a model will be used in.
  - It could be overridden by the EDA tool, for example if the user knows the
    value.
- Radek: If the user is the one who knows the answer, then you have to expose
         all these terminals and not allow any unused terminals.
- Walter: Bob, the model maker could conceivably know.
  - He might know that this package is for a memory chip designed to go on a
    DIMM board.  He might know the DIMM board is going to be 55 Ohms on the DQ
    and maybe 40 Ohms on the address command.  This is possible, but unlikely.
  - I don't think this feature is particularly useful, but it's just a bit of
    extra work for parser.
- Bob: Walter's example, a model pre-designed for something, shows a case where
       this might be useful.
  - If we do add it, I think it should be in two vertical columns, the unused
    port number itself and then the resistance value.
- Discussion: The group agreed that the two-column solution would be good for
  human readability and error checking.  Walter noted that it would make the
  file longer in terms of the number of lines, but said he didn't think this
  feature would be used much.  Mike noted that if we were going to have two
  columns (unused port and value, one each per line), then we could just add
  them as terminal lines with Terminal_type pin_unused instead.  Arpad liked
  this suggestion.  Bob objected to the suggestion and said he did not want
  to add more optional syntactical variations to the terminal lines (i.e.
  potential for an extra column for per-port resistances).  He also noted that
  part of the benefit of the unused-port shortcut was reducing the number of
  terminal lines.  He said he preferred that any Unused_port_terminations stay
  a separate Subparameter.  Mike noted that Subparameters typically had not
  involved multiple rows of data after the Subparameter.  Arpad agreed there
  was precedent for repeating the Subparameter name each time (with each value
  or row) in the [External Model] Subparameters (e.g. Converter_Parameters,
  Ports, etc.).  Arpad noted that he didn't like this redundancy.  The group
  decided to stay with Bob's idea of two columns of data under a single
  Unused_port_terminations Subparameter.

  Arpad brought up his question about the redundancy of "Open" and some
  discussions with Brad Brim.  He noted that "Open" might be handled with a
  value of "Inf" in the Unused_port_terminations.  If that were not acceptable,
  then perhaps for the sake of consistency we should add "Short" as another
  option for Unused_port_termination_directive.  Bob objected to the idea of
  "Inf", and said that for the parser's sake and precedent he disliked the
  idea of mixing numbers and enumerated text values like "Inf."  The group
  discussed adding "Short" as an option for Unused_port_termination_directive.
  Walter and Bob disliked the idea, and Walter noted that he thought "Open" was
  a more useful and meaningful concept than "Short" in an interconnect scenario.
  The group decided "Short" was just as easily handled with a value of "0.0"
  as the Common_resistance, so no changes were made in this area.

- Arpad: What do we have for ARs to resolve this?
- Radek: I can update the current v2 draft with the new two-column
         representation of Unused_port_terminations, if Bob can provide his
         suggestions for the format.

- Curtis: Motion to adjourn.
- Mike L.: Second. 
- Arpad: Thank you all for joining.

AR: Bob and Radek to produce a new draft of BIRD189.5 containing the two-column
    format for Unused_port_terminations.

-------------
Next meeting: 07 November 2017 12:00pm PT
-------------

IBIS Interconnect SPICE Wish List:

1) Simulator directives

Other related posts:

  • » [ibis-macro] Minutes from the 31 October ibis-atm meeting - Curtis Clark