Minutes from the 28 November ibis-atm meeting are attached.
IBIS Macromodel Task Group
Meeting date: 28 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
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:
- Arpad reviewed the schedule for upcoming ATM meetings. The group plans to
cancel the meetings on December 26th and January 2nd. All other meetings
in December will be held as usual.
-------------
Review of ARs:
- None.
--------------------------
Call for patent disclosure:
- None.
-------------------------
Review of Meeting Minutes:
- Arpad: Does anyone have any comments or corrections? [none]
- Walter: Motion to approve the minutes.
- Curtis: Second.
- Arpad: Anyone opposed? [none]
-------------
New Discussion:
BIRD189 - File_TS reference terminal connection to node 0?
- Arpad: [Sharing his recent email describing his new proposal]
- Background: My observation is that even if we make a note or warning about
consistency of usage, "either use node 0 as a reference for everything or
not at all", we will have trouble in practice.
- Suggesting or enforcing consistency requirements is impossible if the user
has models from multiple vendors in the same simulation.
- Also, we aren't going to change the IBIS-ISS specification now and disallow
an IBIS-ISS subcircuit from connecting to node 0 internally, so we have
another consistency issue.
- [sharing a picture of a 4 port (5 Terminal) package connecting two power
pins to two power pads]
- If we don't provide a way for the user to connect the N+1 (5th) terminal
to node 0, someone might be tempted to use their Vss pin as the reference.
But that would essentially short that port with its own reference
(that port's two terminals would be the same).
- Therefore, I think we need a way to specify ideal node 0 as a reference.
- Proposal:
- New Terminal_type called Ref_node. (used to connect to ideal node 0)
- New Terminal_type_qualifier called node_name.
- New Qualifier_entry rule. When the Terminal_type_qualifier is node_name
the <pin_name_entry> shall be A_gnd. (use A_gnd from [External Model]).
- New rule: Aggressor_Only is not allowed with Terminal_type Ref_node.
- At the end of the Aggressor_Only section add the following rule and
warning:
Terminal_type Ref_node is not required for File_TS or File_IBIS-ISS, but
if present, File_TS may only have it only on the N+1th terminal line
(once), while File_IBIS-ISS may have it on any of its terminal lines any
number of times.
Important: It is highly recommended to not use A_gnd for referencing
purposes on terminal lines and to not use ideal ground (node0)
connections inside IBIS-ISS subcircuits.
- Walter: I agree with the functionality you're looking to add, i.e., the
ability to connect a node in File_TS or multiple nodes for IBIS-ISS
to node 0.
- What's the easiest way to implement this in terms of text of the BIRD, ease
for the model maker, and ease for the EDA tool?
- What if we just say, "If Terminal_type is A_gnd, then it's ideal node 0."
- Arpad: Just make Terminal_type itself A_gnd?
- Yes, I think that's simpler, and it would eliminate most of my new rules
and changes. But the final rule and warning would largely be the same?
- Walter: I think it would be easier to state that A_gnd is only allowed on
terminal N+1 of a File_TS.
- Arpad: Walter's suggestion is fine by me. I'm happy to consider changes.
- Bob: Walter's suggestion is valid and simplifies the proposal.
- Aggressor_Only is automatically excluded when Terminal_type is A_gnd,
because it's only for I/O terminals.
- Radek: One of the suggestions I'd made for dealing with the issue of node 0
appearing in an IBIS-ISS was to make sure node 0 was available to the
rest of the circuit.
- But just exposing A_gnd is not the end of the story. You still have to make
sure A_gnd (node 0) is present among the nodes the interconnect model is
actually modeling.
- If you just let one component connect to A_gnd, you have the same ambiguity
we discussed regarding File_TS0.
- We have to be precise about how many components in the model need to be
connected to the various nodes. Only the buffer terminals and pin terminals
can appear only once. All of the other nodes must appear at least twice in
order to guarantee proper connectivity.
- Walter: I think one of the requirements (maybe implicit) of BIRD189 is that
you should be able to use it to wrap package models that are currently
being developed. BIRD189 should be able to wrap them in a way that is
compatible with the way people are making and using them today.
- I think you'll almost always find that models reference node 0. They
reference node 0 on their W-lines, S-parameters, capacitors, etc.
- It's valid to argue that this may be incorrect for power-aware simulations.
But even that is not necessarily true. Scott sent out a very detailed
explanation about how you can use ground based power-aware simulations and
get perfectly valid results.
- So, to say "it is highly recommended to NOT use A_gnd" is incompatible with
the way people make models today. I think it would be okay to note that
since power-aware simulations are becoming more important, one should not
use A_gnd in an attempt to do power aware simulations without using ground
based simulation techniques.
- Radek: We are talking about two different things.
- You make a measurement with respect to your ground (set by the measurement).
- In the simulation, you either have the same environment as measurement, or
if you're using that model elsewhere you have to connect that ground to
something meaningful for your circuit. You can't just connect it to global
ground without any regard for the real schematic ground (local ground)
chosen by the user for the area the interconnect model is covering.
- If you want to be able to connect to global ground, with no knowledge or
concern for where the local circuit is, then you need the restrictions on
the Touchstone data that I defined during the File_TS0 discussions.
- Walter: I'm just trying to quantify the requirement you want.
- What I said was if you do ground-referenced power modeling, meaning you
take Vss and everything "0" and tie those nodes to ideal node 0 (so you can
say Vss is 0V relative to ideal node 0), then everything can work fine. If
the simulator did that, then everything is fine and it can do power-aware
simulations. You just have to adjust the PDN models for Vdd, but that is
what people are doing today.
- Arpad: I understand your point. But I see a dilemma here.
- We basically have two modeling styles, the ground-referenced style, in which
all the parasitics are rolled into the upper (power) side of the model, and
the other style in which power and ground parasitics are kept separate as an
inductance loop.
- In order to do one or the other style, the entire simulation deck has to
follow the same convention. Can we talk about consistency if the user might
have to simulate with models from different vendors made one way or the
other way? How can we best verbalize the warning?
- Radek: The warning is fine. You are saying there's an issue, and there's a
requirement if conditions aren't met. It tells people it's perhaps
best not to use node 0.
- Bob: If we go with Arpad's proposal, with Walter's simplifying modification,
then the warning is easy to check for A_gnd. Any time A_gnd shows up as
a Terminal_type, it's a warning. But catching use of node 0 in IBIS-ISS
subcircuits or detecting another Touchstone file with an N+1 terminal
that isn't connected to node 0 is hard, so detecting incompatibilities
is hard.
- Discussion: The group discussed the wording of a warning sentence to be
included in the BIRD and arrived at:
"Power-aware simulations may require that A_gnd NOT be used as a reference
for interconnect models, or that ideal ground (node0) NOT be used inside
IBIS-ISS subcircuits."
With the group's approval, Arpad took the AR to write up a new draft of the
BIRD for discussion at the Interconnect Meeting the following day. Bob noted
that there would be additional vetting to do.
- Arpad: If this BIRD189 discussion now moves back to Interconnect, what topics
should we discuss next week?
- Walter: I think item #8 (single ended applications of AMI - DDR5) should be
tabled. Everyone understands that there are various issues that may
make it invalid. But it's still unclear what should be done.
- Discussion: Walter moved to table item #8. Radek seconded. No one was
opposed. Bob said he thought item #7 (C_comp improvements) should be tabled
until BIRD189 is finalized. Bob moved to table item #7. Walter seconded.
No one was opposed.
- Arpad: All our topics are tabled.
- We will continue to hold the meeting and discuss topics as they arise,
perhaps related to or suggested by Interconnect meetings.
- Mike L.: I'd like to add an item to discuss Forward Error Correction. I can
give a presentation on what I've heard from Asia.
- Bob: I'd like to review a presentation by Raymond Chen.
http://ibis.org/summits/jun05/chen.pdf
- Arpad: Let's all review that presentation for next week's discussion.
- Thank you all for joining.
AR: Arpad to prepare BIRD189.5_draft11_v2 with his proposed A_gnd changes.
-------------
Next meeting: 05 December 2017 12:00pm PT
-------------
IBIS Interconnect SPICE Wish List:
1) Simulator directives
