Minutes from the 06 March ibis-atm meeting are attached.
IBIS Macromodel Task Group
Meeting date: 06 March 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 and BIRD158 related issues:
- Arpad: At the Interconnect meeting they wanted us to review BIRD158 in the
context of BIRD189. Radek had raised some issues.
- Bob: Should we go into the "ground" discussion?
- Arpad: Anything strictly BIRD189 related should be handled in the Interconnect
meeting, but the ground issue is part of the BIRD158 vs BIRD189
issue, so we could discuss it here.
- Radek: [having Arpad share his 'BIRD158 and BIRD189 Referencing Problems'
slides from the ATM meeting on February 20th, 2018]
- [BIRD158 figure showing the entire channel topology]
- Diagram shows the channel, package, etc., and the 4 port S-parameter data
provided by the Ts4File.
- This is an AMI specific configuration.
- The different pieces can be characterized with Touchstone files.
- Figure shows a common reference for all of them, as we have discussed.
- The real point is that the package should also be represented as a 4 port,
and all of the terminals shown here are the I/O terminals, and this common
reference node for all of them is the A_gnd (the local ground).
- But a BIRD189 package model may not be created this way. It may also include
other terminals related to the rails. We need to address that.
- What we need in BIRD158 is the 4 port structures that span the I/O terminals
and the common reference we will term A_gnd.
- Interconnect model maker may provide exactly that, a 4 Port Interconnect
model that spans pairs of differential I/O pins with A_gnd as the reference.
- IBIS-ISS can be used as well, but the point is that A_gnd should still be
there as the reference for the channel.
- The problem is if the interconnect model provides other terminals for the
rails, then we don't have a solution for that yet. My solution would be to
tie one of the rails to A_gnd for this BIRD158 AMI application.
- Walter: [sharing a private email related to common references]
- There are three types of simulations:
- 1. Not Power Aware
- All rail voltages are DC voltages.
- All reference nodes are connected to a "ground" node (i.e. a rail
voltage with DC level 0V relative to a simulator global reference, e.g.
node 0) or a single simulation reference node.
- 2. Ground Based Power Aware
- The voltage rails that are not "0" can vary with time and float.
- All "ground" rail nodes are connected to a "ground" node (i.e. a rail
voltage with DC level 0V relative to a simulator global reference, e.g.
node 0) or a single simulation reference node. (e.g. tie all your VCC
rails to node 0).
- All reference nodes are connected to a "ground" node (i.e. a rail
voltage with DC level 0V relative to a simulator global reference, e.g.
node 0) or a single simulation reference node.
- 3. Power Aware, where local "ground" nodes can float relative to a
simulator or simulation reference node.
- This requires an understanding by both the model maker and the tool he
is using to generate interconnect models that correctly reference
appropriate rail terminals at the buffer/die and at the pin.
- BIRD189 allows the model maker and tool to create models with reference
terminals that satisfy this requirement.
- The model maker should document if all of the Interconnect Models in all of
the Interconnect Model Sets in an Interconnect Model Group support case 3.
- We may choose to add a keyword to the [Interconnect Model Group] that
indicates that the Group is fully power aware.
- Note that a fully power aware model can still be used in scenarios 1 and 2
by tying the references to 0V.
- BIRD158 simulations are for AMI. They are LTI. They are not power aware
when generating step responses for AMI simulations. It doesn't matter what
the user did connecting reference nodes. The EDA tool is going to do a non-
power aware simulation and tie all those reference nodes to A_gnd or node 0.
- We may want to write this up more carefully along these lines, but there is
nothing wrong with the existing format we have.
- It just means that when someone is doing full power aware simulations that
support the local ground node floating relative to node 0 they have to do it
carefully.
- I think text along these lines (3 types of simulation) could be added to the
justification for the BIRD, or the BIRD text itself, and that could be the
end of this discussion on A_gnd and power aware simulations.
- Bob: I largely support what Walter has said.
- I would add a clarification statement that for BIRD158 the full capability
of BIRD189 is not supported nor relevant.
- Walter: I don't agree with that statement. A fully power aware BIRD189 model
is supported properly by BIRD158. You just recognize that you're not
doing a power aware simulation with BIRD158, and tie the rail
voltages to DC levels.
- Radek: That's exactly what I've been asking for. We have an Interconnect
Model Group, and we should spell out for the EDA tool and the user
exactly how things should be handled for the application of BIRD158.
We agree, but we have to spell it out.
- Arpad: We are converging on a solution.
- Which BIRD should be modified to add this text?
- Radek: I think BIRD158 is okay already.
- In BIRD189 we may want to add clarification on how models are used in AMI or
non-power aware simulations.
- Arpad: [referring to the "triangle ground symbol" Note that appears 3 times
in BIRD158 (at the bottom of his full channel topology slide)]
- Should we change the sentence:
"This node would typically be the global ground, such as node 0 in
IBIS-ISS."
and replace the node 0 reference with the A_gnd we use in BIRD189?
- Should we remove the "typically", which allows the EDA tool to do whatever
it wants? Should we mandate the use of A_gnd?
- Radek: We can't mandate the use of A_gnd for the channel block. That
connection is made by the user or tool. The best solution is probably
to remove that sentence entirely.
- We already say (previous sentence) that they're all the same node. When
we have BIRD158 used in conjunction with BIRD189, BIRD189 will say that node
is A_gnd.
- Discussion: Arpad noted that with the current understanding of A_gnd as a
"local ground", it was local to a given component. Therefore, a Tx on one
end and an Rx on the other might have A_gnd connected to different nodes.
He therefore preferred to have BIRD158 state that the reference node for the
TS4 file blocks is A_gnd, the local ground. Bob noted that BIRD158 did not
have anything in its syntax to specify the reference node. Arpad noted that
in the context of the recently added warning in BIRD189 strongly suggesting
the use of A_gnd as the reference for the package model, a similar statement
in BIRD158 that A_gnd would be the reference for the Ts4file Touchstone block
made sense. Ambrish expressed concern for mixing the BIRD158 and BIRD189
warnings in case a model maker only wanted to read the BIRD158 section. He
suggested BIRD158 might just need an additional warning that BIRD158
simulations are not power aware. Walter noted that BIRD158, since it is an
impulse response based simulation, only requires the references to be
connected to DC voltage levels. Radek suggested we might state that all
ground references are assumed shorted to A_gnd in the absence of any more
specific information. Arpad proposed a combination of Ambrish's warning with
Radek and Walter's ideas, and said that we might state that if BIRD158 is used
with a BIRD189 model, then the model maker should probably use A_gnd as the
reference for the BIRD189 model.
Arpad said he would take the AR to make this BIRD189 related cleanup
to BIRD158. Since BIRD158 (BIRD158.7) is already approved, he asked what the
group thought was the best way to do it. Bob disliked the idea of re-opening
BIRD158. Arpad agreed to create a new BIRD that starts with the BIRD158.7
text and indicates the required changes.
Mike L. asked why BIRD158 even showed the package model and channel in the
figure. Arpad said it was to show common referencing for the entire channel.
Arpad revisited slides 3 and 4 from his Feb 20th presentation. He noted
that these illustrated the same thing as the full channel figure in BIRD158.
He again discussed the possibility of an N+2 channel model, and he suggested
that the current BIRD158 assumption that all the reference nodes are the same
was not necessary. Walter noted that we could dramatically complicate the
language of BIRD158 with additional changes, but that in practice we can
safely assume that the reference nodes are tied together for BIRD158
simulations. He said when people build SERDES channels they are extremely
careful to make sure all the references throughout the channel are well
connected. Ambrish noted that he disagreed with Walter's statement.
BIRD189: Rail Rule Relaxation:
- Discussion: Arpad shared some figures he had created previously for a
different discussion to illustrate the suggestions in Bob's Rail Rule
Relaxation proposals. Walter noted that he thought the rule relaxation was
unnecessary, and that we had demonstrated that decoupling cap modeling could
be handled to Randy's satisfaction with the current BIRD189. Further
discussion was deferred to the next Interconnect meeting.
- Ambrish: Motion to adjourn.
- Walter: Second.
- Arpad: Thank you all for joining.
AR: Arpad to prepare a draft of a new BIRD to supersede BIRD158.7.
-------------
Next meeting: 13 March 2018 12:00pm PT
-------------
IBIS Interconnect SPICE Wish List:
1) Simulator directives
