[ibis-macro] Minutes from the 07 November ibis-atm meeting

  • From: Curtis Clark <curtis.clark@xxxxxxxxx>
  • To: IBIS-ATM <ibis-macro@xxxxxxxxxxxxx>
  • Date: Mon, 13 Nov 2017 19:31:44 -0500

Minutes from the 07 November 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
08-NOV-2017 Arpad Muranyi Mentor, A Siemens Business BIRD 165.1 draft 1 (zip
IBIS Macromodel Task Group

Meeting date: 07 November 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.


- Arpad asked if we should consider cancelling next week's meeting because of
  the IBIS Summits in Asia.  Bob noted that he thought Mike LaBonte was the only
  regular attendee who would be at the Summits.  Arpad decided we should hold
  next week's ATM meeting as usual.

Review of ARs:

- Bob and Radek to produce a new draft of BIRD189.5 containing the two-column
  format for Unused_port_terminations.
  - Done.
  - Discussion: Arpad noted that this had been done, but he asked if it had been
    rolled into a new draft.  Bob noted that at a subsequent meeting
    (Interconnect meeting last Friday) a vote had been taken to roll back the
    two column solution and get rid of per port impedance.  Radek said it had
    been voted out without further technical discussions, and that he felt we
    should discuss it in the ATM meeting since it had been discussed here too.
    Arpad said we could continue to discuss it in ATM.  Walter suggested that
    the decision had been made in the Interconnect meeting, that there was no
    reason to discuss it further here, and that it could be taken off the ATM
    agenda.  Walter suggested someone could reopen the discussion in the future
    if they wanted to do so.
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:

- Arpad: [sharing BIRD165.1 draft 1]
  - BIRD165 was introduced in 2014.
  - I've made significant changes to the "Statement of the Issue" section, but
    these are non-technical improvements in the wording.
  - The "Any Other Background Information" section lists the changes made to
    create this draft.  It also defines the color scheme:
    - green - differences between this and the IBIS spec.
    - change tracking (in red) indicates differences between this draft and the
      original BIRD165.
  - Original BIRD165 was written relative to IBIS 6.0.  This version updates the
    page number references relative to IBIS 6.1.  The text being changed is no
    different in 6.1 than it was in 6.0.
  - [Circuit Call] keyword section is modified.  It gets text duplicating the
    parameter passing stuff from [External Circuit].
  - Parameters and Converter_Parameters are added as Sub-Params.
  - New (duplicated) sections describe what they do.
  - Rules for using them are the same as for [External Circuit], except that if
    they exist in [Circuit Call] then they override any values in the [External
  - Only other change is the modification of the Figure 29 example to include
    an example of the use of Parameters (change on pg. 134) in [Circuit Call].
  - Walter asked me the purpose of the Parameter "C1_value" that has nothing
    following it.
    - This is what we had before parameterization was added in in 6.0.  This is
      the old syntax, where the value wasn't given and it was presumed the tool
      would allow the user to enter values for the parameters.  Having it in the
      example just shows this old syntax is still available, though it doesn't
      seem very useful.
- Radek: My only issue is the "C1_value" example Walter brought up, but I 
         understand your explanation.
  - The logic behind this proposal is good.  It's good to differentiate between
    different instantiations.
  - I'm not sure the "will be in effect" (override) is necessary or not, but
    when you instantiate a subcircuit you don't have to specify values for all
    the parameters in the subcircuit.
- Arpad: With regard to the "C1_value" example:
  - I agree with you and Walter that this doesn't make a lot of sense.
  - But this was the only thing we had before IBIS 6.0.  The idea was that
    listing the parameter names would allow the tool to create some GUI listing
    the parameters so the user could provide values.
  - The reason we added parameter values is that the IBIS file was at least a
    place to consolidate and maintain all the values, so the user didn't have
    to look up values from all different sources (data sheets, etc.).
  - I wondered if we should deprecate that old syntax, but that makes things
    more complicated.  I felt it was simplest to leave the old syntax, add the
    new syntax, and assume people won't use the old syntax if it's not useful.
- Walter: I can conceive of one reason for the old way.
  - You may have a subcircuit which has a parameter, but the subcircuit
    declaration has a default value.
  - The old syntax might be a way to let the user know the parameter exists,
    but the default value in the subcircuit should be used.
- Bob: We should just keep the old syntax.  If nobody uses it that's fine.
- Arpad: Agreed.
  - I will get this draft to Mike for posting to the ATM archives.

BIRD189 - File_TS0 restrictions.
- Arpad: [sharing Radek's email to ATM from earlier in the day]
- Radek: We started discussing this topic at the Friday Interconnect meeting.
  - This is a serious issue.  The File_TS0 was added for convenience, but it
    hasn't been completely thought out.
  - BIRD189 allows IBIS-ISS or Touchstone data.
    - For Touchstone data, the Sub-param was File_TS.
      - For File_TS, the Number_of_terminals must be N+1.  N ports are defined
        between terminals 1 through N and the N+1 reference terminal.
      - IBIS-ISS, and HSPICE and others allow other forms of S-element component
        that may have N, N+1, or 2N terminals.
      - The N and N+1 forms differ only in what the N+1 terminal is.  When only
        N terminals are specified, it's implicit that the N+1 terminal is global
        node 0.  That's the only difference.  The user could take an N+1 version
        and connect the N+1 terminal to node 0 and get the same thing.
    - Now we've introduced the File_TS0 (N terminals).
    - What are the consequences of that?  Connectivity.
    - The problem is that the implicit node 0 is not required to be present
      throughout the entire span of the interconnect modeling.
    - We have a type of modeling with a number of nodes, which are spanned by
      the interconnect models, and then suddenly we could have a component
      (File_TS0) which is implicitly connected to a completely different node
      outside the set of nodes in the modeled area.
    - So this draft is fundamentally flawed.
    - The only way this might work in its current form, if we want to keep it,
      is the requirement that the data inside the Touchstone file supports the
      possibility of that terminal being connected to anything.  That really
      means that no current is flowing through that implicit terminal into the
      internal part of the component.
    - I added a statement of this requirement for the Touchstone file used in a
      File_TS0 in the third paragraph of my email:
         If the same Touchstone file is used for an S-element with N+1 nodes,
         then for any loading conditions (the external circuitry outside of the
         S-element) and at all frequencies present in the file the current
         entering (or leaving) the N+1st node is zero.
    - That's the general requirement.  This is equivalent to saying that N+1st
      terminal of the component is isolated from the rest of the component
    - We don't have that requirement in the current draft.  I'm not sure the
      parser is capable of checking for it.  If the data is not restricted, we
      have a problem knowing what any EDA tools will do with it.
- Arpad: The original idea behind adding File_TS0 was addressing the case in
         which there are no pins under the [Pin] keyword that are suitable as
         a reference terminal.
  - We discussed the option of using node 0 in that case, and I suggested the
    A_gnd syntax to specify that, but people didn't like that.
  - We couldn't come up with a way of specifying node 0 that everyone liked,
    so the idea of using the special File_TS0 and stating in the rules that
    it is implicitly connected to node 0 was proposed.
  - Isn't it always true that the sum of the currents has to be zero, even
    if this reference node were connected to a pin on the [Pin] list?
  - Wouldn't your restriction be true for File_TS, too?
- Radek: No, in the File_TS case, the N+1st terminal is one of the accessible
         terminals connected in the model.
  - If you had the N+1 version (File_TS) and didn't connect the N+1st terminal
    to anything, then you'd have a problem.  But the model maker uses all
    N+1st terminals.
  - In fact, to address this problem we need to explicitly state that for
    File_TS the N+1st terminal is not allowed to be one of the unspecified ones.
  - There are consequences to the requirement (specified above for TS0) that
    the N+1st terminal is isolated internally from the rest of the terminals
    in that S-element.  There are very strict and necessary conditions that
    lead to the statement I made about the restrictions.
    - The fact that the terminal is isolated leads to the non-existence of
      the Z matrix, which in turn implies the singularity of the Y matrix.
    - Most of the Touchstone files that are out there do not actually meet
      this restriction, but that's only a necessary condition.
- Bob: I disagree with the statement that no current would flow through node 0.
  - Consider a one port case.  Current could flow into terminal 1 and out
    through the implicit reference node (node 0).
- Radek: You disagree with something completely different.  You disagree that
         the Touchstone data for a one port would result in no current flowing
         if you connect it to node zero.  But if you connect it to a different
         node, or change the topology so a different node is your node 0, you
         get completely different results.
- Discussion: Radek said that if File_TS0 involved an implicit connection to a
  node that might not be available to the rest of the interconnect models, then
  the only way to avoid ambiguity and be certain of the results would be the
  "no current flowing through the reference terminal" (reference terminal
  internally isolated) restriction.  Bob thought the other interconnect models
  would have access to the same implicit reference node if necessary.  Bob said
  that he would support adding text explaining that File_TS and File_TS0
  models could not be intermingled without risking dire consequences.  Radek
  said another possible solution was to explicitly add the N+1 terminal in
  the File_TS0 case, so that whatever reference it was connected to was made
  available to the rest of the interconnect models.  Bob noted that BIRD158
  models assumed a File_TS0 style common reference.  Radek agreed that in
  BIRD158 the implied N+1st node is the implicit reference that's used for the
  entire channel.
  Arpad asked Randy about his experience developing S-parameters for on-die
  decap models.  Randy said they had tried some one-port modeling approaches,
  but generally had better correlation results using a two port model with a
  reference to zero.
  Bob noted that the spec already contains a statement about possible issues
  with power-aware simulations using global node 0.  He suggested that we add
  more specific guidance about possible issues mixing File_TS and File_TS0.
  Bob noted that example 4 in BIRD189.5-draft10 actually contains a mix of
  File_TS and File_TS0, and he suggested that the example should be fixed
  because model makers should not do that.  Walter said he thought model makers
  knew enough not to create model configurations that wouldn't work, and that we
  needn't spell out any more rules for them.  Bob said that if we couldn't
  spell out the rules, how could a model maker be expected to do things
  Arpad again asked what we would do in the case when no pin in the [Pin] list
  could serve as the reference, and he again noted that File_TS0 was created for
  this situation.  He said there should be no need for mixed use of File_TS and
  File_TS0, because if a suitable reference pin existed it would be available to
  all of the Touchstone models.  Bob noted that this was not the only reason for
  File_TS0, and he and Walter noted that many model makers distribute Touchstone
  models based on the implicit node 0.
- Walter: Motion to adjourn.
- Bob: Second. 
- Arpad: Thank you all for joining.

AR: Arpad to send the draft of BIRD165.1 to Mike L. for posting to the ATM

Next meeting: 14 November 2017 12:00pm PT

IBIS Interconnect SPICE Wish List:

1) Simulator directives

Other related posts:

  • » [ibis-macro] Minutes from the 07 November ibis-atm meeting - Curtis Clark