[ibis-macro] Minutes from the 27 February ibis-atm meeting

  • From: Curtis Clark <curtis.clark@xxxxxxxxx>
  • To: IBIS-ATM <ibis-macro@xxxxxxxxxxxxx>
  • Date: Sun, 4 Mar 2018 22:11:21 -0500

Minutes from the 27 February 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
27-FEB-2018 Arpad Muranyi Mentor, A Siemens Business Referencing Problems (
zip
<http://ibis.org/atm_wip/archive/20180227/arpadmuranyi/Referencing_Problems.zip>
)(pdf
<http://ibis.org/atm_wip/archive/20180227/arpadmuranyi/Referencing%20Problems/ReferencingProblems_2018_02_27.pdf>
)
IBIS Macromodel Task Group

Meeting date: 27 February 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.

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

- 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:
- Arpad: [sharing his 'Referencing Problems' presentation]
  - Michael M. mentioned at the last Interconnect meeting that we need to put a
    halt on these discussions and come up with a decision.
  - I've prepared some slides to illustrate the referencing issues.
  - [slide 1]
    - For illustrative purposes, I keep distinct node names for all the
      terminals, even if they are shorted  (à la .connect statement in SPICE).
    - Simple S-parameter block.  Unity gain VCVS with a 1 Ohm resistor for the
      Thevenin circuit on each side.
    - All port voltages (difference between port pos and neg terminals) are
      identical.
    - This example shows no connection to "ground".  So it should satisfy tools
      with no concept of node 0.
  - [slide 2]
    - These examples won't give the correct results in any simulator because
      there is no complete loop in the connection between S1 and S2.
  - [slide 3]
    - These examples both work.  It's not required that all the reference nodes
      be the same.  We just need continuity in these loops connecting the
      blocks.
  - [slide 4]
    - Modification of slide 1 - all the reference terminals are shown tied
      directly to node 0.
    - Note that any Ohmic connection to node 0 would do (short, 1G Ohm, 1M Ohm).
    - This provides the DC path to ground most SPICE-like tools want.
    - Now plotting individual terminal voltages (with respect to node 0).
    - All reference terminals are 0 (node 0).
    - All positive terminals show the identical waveform (same waveform seen in
      the port voltage plots in slide 1).
  - [slide 5]
    - Same circuit, except that each block's common reference is now tied to a
      different node with a different DC offset (relative to node 0).
    - Common references for each block, but because each block's reference is
      different the port voltages for ports 3 and 4 are not the same as ports 1
      and 2.
    - The different DC references for the blocks cause incorrect results.
    - [David Banas noted that the AC waveforms on the positive terminals were
       unchanged.  Arpad agreed.]
  - [slide 6]
    - Like slide 5, but add "noise" to the DC sources connected to the reference
      terminals.
    - We might have an IBIS Tx on one end of a ground plane and an IBIS Rx on
      the other end.  The ground plane will have noise unless it's ideal.
    - Noise effects couple into the port3 and 4 voltage waveforms.
    - This is why I firmly believe that if we allow different references to be
      used for the different blocks in an interconnect model we could get
      incorrect results.
  - [slide 7]
    - Proposed solution 1 for IBIS.
    - Require all reference nodes to be tied together (but not necessarily to
      node 0).
    - Even with the non-ideal noisy reference the output port voltages are as
      expected.
    - This is the simplest solution in terms of minimizing changes to our
      current BIRDs.
  - [slide 8]
    - This is the more general N+2 approach.
    - Just make sure we have the same reference for the connected terminals of
      adjacent blocks.
    - In this example each of the three references has a different "noise"
      source, but the final port voltages are still correct.
    - This would be significantly more work in terms of updating the BIRDs.
    - Going from N+1 to N+2 would involve lots of changes.
    - For expediency's sake, I think it's okay go with the approach (slide 7)
      that the reference for all ports is the same node.

- Discussion: David Banas asked if the N+2 approach would cause compatibility
  problems for tools, for example because SPICE typically supports N, N+1 or
  2N terminal approaches.  Arpad noted that N+2 is a subset of the 2N approach,
  with half of the reference terminals tied to one node and the other half tied
  to a second node.

  Walter noted that the example in slide 8 (N+2) could be handled by wrapping it
  in a subcircuit instead of using the Touchstone shortcut in BIRD189.  He also
  noted that adopting the N+2 syntax would mean adding more syntax to define
  which were the "left" and "right" ports.  Arpad agreed that this was part of
  the significant effort that adopting N+2 would entail.  Walter recommended
  that we stay with N+1, and that we make it a rule or a note that the same node
  should be the reference for all blocks.  Arpad noted that keeping the N+1
  approach without mandating that all of the N+1st terminals were connected to
  a common node would leave us open to the bad results seen in slide 6.  Arpad
  preferred that we clean up BIRD189 to say that all Touchstone devices'
  reference terminals were tied to the same node.

  Radek reiterated that N+2 offered no real advantages.  He also reiterated his
  preference for using the A_gnd in BIRD189 as the way to specify the common
  reference node, instead of its current use in specifying node 0 as the
  reference for particular blocks.  Arpad agreed that we could adapt A_gnd to
  serve as the common reference for all Touchstone shortcut blocks.

  Radek noted that in slide 2 the simulator would probably give you the "right"
  answer, but it gives you the answer based on the way the connections and
  circuit configuration are specified.  However, we have to remember that one
  important aspect of the simulation may or may not be correct with respect to
  what's inside the S-parameter block.  When the model maker creates a 2 port
  model with 4 terminals (2N), that's a specific decision that is made to do it
  that way (as opposed to the N+1 approach).  He noted that he'd discussed the
  issues with that extra degree of freedom before.  The simulator is likely to
  address this extra degree of freedom by enforcing that the currents entering
  and leaving port 1 must be equal, and the currents entering and leaving port
  2 must be equal.  You get a solution based on this condition.  Whether this is
  true for the actual circuitry inside the S-parameter block is a separate issue
  we have to be aware of.  Radek noted that he hoped to prepare some language
  on how the external circuitry may interact with the way N-port devices are
  treated internally.  He hoped to have this language ready for the Friday
  Interconnect meeting.

  Bob asked if Arpad had indeed meant 2-port devices for all the blocks.  Arpad
  confirmed that he had, and noted that he had shown 4 terminals in all the
  examples for consistency.  For the N+2 examples they are required, but for the
  typical N+1 examples he had shown the two reference terminals tied together
  externally.  To clarify things based on this discussion, Arpad redrew the
  examples on the right hand side of slides 2 and 3 to show the two ports'
  reference terminals tied together within the block and only 3 terminals
  emerging from the block (N+1 scenario). [this appears in the posted version]

  Radek noted that slide 5 relates to the issue he discussed with BIRD158 in the
  context of BIRD189.  We have this issue with a BIRD189 model that may contain
  the rails as well as the I/O, but the BIRD158 model only addresses the I/O.
  Radek noted that we might address this by extending the A_gnd idea to the
  BIRD158 models so the rail could provide the reference for BIRD158 models.
  Radek noted that Arpad's observations in these slides was consistent with what
  he wanted to propose.

  Walter noted that only DC offsets were introduced in the slide 5 example.  He
  noted that the AC levels were not altered in this example.  Based on this, he
  suggested that the only requirement for BIRD158 might be that each reference
  terminal is connected to a constant level voltage source.  Since BIRD158 is
  for AMI, and AMI uses an impulse response to characterize the channel, any
  DC shifts in the final port voltage waveform don't matter.

  Arpad noted one other thought experiment he had done.  Instead of connecting
  all the reference terminals together, what if the "channel model" in the 
  middle of the simulation were the lone N+2 model?  Then, all the blocks on the
  Tx side of the channel could be connected to one reference, and all the
  blocks on the Rx side of the channel could be connected to another reference.
  As long as the channel model block were N+2, it would be like having an
  isolation transformer in the middle. 

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

-------------
Next meeting: 06 March 2018 12:00pm PT
-------------

IBIS Interconnect SPICE Wish List:

1) Simulator directives

Other related posts:

  • » [ibis-macro] Minutes from the 27 February ibis-atm meeting - Curtis Clark