Minutes from the 20 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
20-FEB-2018 Arpad Muranyi Mentor, A Siemens Business BIRD 158 and 189
Referencing Problems (zip
<http://ibis.org/atm_wip/archive/20180220/arpadmuranyi/BIRD_158_and_189_Referencing_Problems.zip>
)(pdf
<http://ibis.org/atm_wip/archive/20180220/arpadmuranyi/BIRD%20158%20and%20189%20Referencing%20Problems/ReferencingProblems.pdf>
)
IBIS Macromodel Task Group
Meeting date: 20 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:
- Arpad and Mike L. to fold changes discussed during the meeting into draft17_v2
to create draft17_v3.
- Done.
--------------------------
Call for patent disclosure:
- None.
-------------------------
Review of Meeting Minutes:
- Arpad: Does anyone have any comments or corrections? [none]
- Mike L.: Motion to approve the minutes.
- Radek: Second.
- Arpad: Anyone opposed? [none]
-------------
New Discussion:
BIRD189:
- Arpad: [sharing his 'BIRD158 and BIRD189 Referencing Problems' presentation]
- Radek suggested that we all take an AR to discuss compatibility problems
between BIRD189 and BIRD158.
- I think we do have a potential problem.
- [slide 1]
- Shows the three circuit topology drawings from BIRD158.
- It also includes the "Note:" that appears 3 times in BIRD158 regarding
the triangle symbols representing the same node.
- Typically that node is node 0.
- We don't enforce it as node 0, but the key is that they represent the
same node.
- [slide 2]
- Illustrates what a combination of the two BIRDs could do.
- Uses Vladimir's notation from his S-parameters presentation at the
DesignCon IBIS Summit. Dotted lines explicitly indicate the reference
terminal for each port.
- Illustrates that for BIRD158 the reference node is most likely node 0
(though not required), but in BIRD189 there is no requirement for what
node the reference terminals should be connected to.
- This example shows a BIRD189 on-die model with different reference than
the BIRD158 model. This is valid according to the syntax but could be
mathematically problematic.
- [slide 3]
- An abridged version of the entire end-to-end flow.
- Not even showing the reference for the channel model, since the EDA tool
could do what it wants.
- Every block could potentially have a different reference.
- Big question is: How could we guarantee this won't happen?
- The only thing we have right now on this subject is the BIRD158 Note.
- [slide 4] - Recommendation from Vladimir
- I thought we might consider a strict rule requiring all the reference
nodes to be node 0.
- Vladimir thought this would be too restrictive. He proposed this N+2
syntax (different reference terminal for the left (input) and right
(output) terminals, so connected blocks can share the same reference
for their connected terminals).
- This makes it easier to connect the blocks (one reference on each side).
- It also makes it conceptually closer to the way data would be measured.
- Discussion: Radek agreed with the slide 1 statements. For slide 2 he noted
that what was depicted (PD_ref and Vss_pin used as references) would be wrong
unless information in the BIRD189 model described the connectivity of
those nodes, or unless the Touchstone data met specific conditions that
meant that no current flows to those reference nodes. Radek referred to his
previous comments that if the N+1st reference node could be connected to
something outside of the modeling area, then there must be no current flowing
through that node (see 2017/11/14 ATM minutes, for example). Radek noted that
Arpad's figures did not address another issue with BIRD189 in the context of
BIRD158: BIRD189 models might contain power pin information, while BIRD158
was confined to I/O pins. Radek noted that this issue might need to be
addressed more urgently than any referencing issue. Radek noted that the N+2
proposal was similar to a W-element configuration. He said this was okay,
but noted that even Vladimir's presentation had pointed out that this
could lead to an under-determined system, and we gained nothing by having
different ends of the channel having different references. He noted that in
other contexts we had decided to stick with the N+1 scheme.
Bob noted that slide 2 illustrated two potential problems. The connection
between the first two blocks showed a potential issue with BIRD158 connecting
to BIRD189. The second connection showed potential inconsistencies within a
BIRD189 Interconnect Model Set. He also noted that an N+2 scheme would be
a significant syntax change.
Arpad noted a concern that no matter what we did in these BIRDs we can't
prevent one model maker who made the Tx and another model maker who made
the Rx from having inconsistent referencing conventions. Radek said this
was not an issue, and the user connects the model to the channel and has all
the options they need for defining the reference. It's up to the tool/user
to connect the references properly.
Radek noted that even IBIS-ISS would have to be extended to support the N+2
proposal. Arpad noted that this wasn't really an issue in this discussion.
IBIS-ISS could be improved in that regard, but BIRD158 explicitly skips the
use of an IBIS-ISS wrapper, and if the model maker is using an IBIS-ISS
wrapper in BIRD189 they are free to define the ports as they wish. Arpad said
he thought the question for us at this point was whether we should mandate
the node 0 reference or consider the N+2 proposal. Radek said he would prefer
we not mandate node 0. He preferred that we maintain the A_gnd syntax for
BIRD189 to define a common reference, but that it not be forced to be node 0.
Walter noted that he thought the entire discussion was a waste of time. He
said that in practice everyone uses node 0 as the reference for their
S-parameter simulations, except possibly in power aware simulations. Since
BIRD158 simulations are clearly not power aware, using anything other than
node 0 didn't make sense. Similarly, for BIRD189, if you're using the
Touchstone file shortcut then node 0 should be the reference. Arpad asked why
why the N+1 solution was used for the shortcut? Walter said he had originally
proposed an N terminal solution with node 0 assumed as the reference, but
others objected.
Radek reiterated that very specific conditions had to be met by the data in a
Touchstone file if you were going to assume the reference terminal could just
be connected to any node outside of the modeled area. In that case the
reference terminal had to be isolated from the other terminals in the device.
Radek gave the example of a simple resistor. He said if you made a one port
model for the resistor, you would not assume you could connect that reference
terminal to any old node and not affect the simulation results. Walter noted
that you should model that resistor with a 2 port model. Radek agreed that it
could be done that way, and said this model would meet the strict mathematical
requirements he wanted to add to the language of the spec.
- Mike L.: Motion to adjourn.
- Curtis: Second.
- Arpad: Thank you all for joining.
-------------
Next meeting: 27 February 2018 12:00pm PT
-------------
IBIS Interconnect SPICE Wish List:
1) Simulator directives
