Minutes from the 14 November ibis-atm meeting are attached.
IBIS Macromodel Task Group
Meeting date: 14 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.
--------------------------------------------------------------------------------
Opens:
- Arpad reviewed the schedule for upcoming ATM meetings. The group decided to
cancel the meetings on December 26th and January 2nd. All other meetings,
including next week's, will be held as usual.
-------------
Review of ARs:
- Arpad to send the draft of BIRD165.1 to Mike L. for posting to the ATM
archives.
- Done.
--------------------------
Call for patent disclosure:
- None.
-------------------------
Review of Meeting Minutes:
- Arpad: Does anyone have any comments or corrections? [none]
- Dan: Motion to approve the minutes.
- Randy: Second.
- Arpad: Anyone opposed? [none]
-------------
New Discussion:
BIRD165.1:
- Discussion: Bob said he thought the posted draft looked good and was ready to
submit. Radek agreed. Arpad noted that Walter had said in last week's
meeting that he thought it was ready. Arpad said he would submit it to the
Open Forum as BIRD165.1. No one objected.
BIRD189 - File_TS0 issues.
- Radek: Last week's discussion was continued in the Interconnect meeting.
- Could someone summarize those discussions for those of us who didn't
attend the Interconnect meeting?
- Arpad: [sharing the minutes from the Interconnect meeting]
- Radek: [reviewing and responding]
- Mixing File_TS and File_TS0 isn't the problem.
- File_TS0 itself is the problem.
- I don't oppose the File_TS0 idea altogether. In its current form, I think
think it's a mistake because it lets a component include a node outside
the span of the nodes covered by the interconnect model.
- If a draft required one of the power rails or something else to connect to
ideal node 0, to expose it to the rest of the circuit being modeled, that
would be okay. Otherwise we have to make it clear that there are severe
restrictions on the Touchstone data if we want to ensure it's used
unambiguously and correctly.
- Bob: You could oppose File_TS0 entirely, or you could accept File_TS0 but
acknowledge that one has to be careful when using it. The use of it
is the technical concern right now.
- Do you oppose it entirely?
- Radek: The usage for File_TS0 is very clear, because the draft says that
reference is connected to node 0.
- What I'm saying is that if node 0 is not spanned by the interconnect
modeling package, then it's entirely outside the modeling area. In that
case there are very strict restrictions on the data in the Touchstone file.
People need to be aware of the restrictions on allowable Touchstone data.
- Arpad: Radek, what would you propose instead of File_TS0?
- It sounds like you're unhappy with File_TS0, but how would you solve the
issue it was intended to address?
- What if we just found a way to do everything with a File_TS (N+1 terminals)
and have the user explicitly connect the N+1st terminal to node 0?
- How would that be different from File_TS0? Regardless of the File_TS or
File_TS0 syntax, the user could still make a mistake and connect the rest
of their model improperly.
- Radek: The question is what do we want to do?
- If you really want that connected to global ground, then either:
- Global ground has to be present in the set of nodes spanned by the model.
- or
- The connection to global ground has to have no effect.
- Whatever we decide must be unambiguous and correct.
- I could propose removing File_TS0 altogether.
- Then you have the N+1 nodes (File_TS), and the N+1st node is one of the
nodes used for connections.
- Regardless of what we call that global ground node, if we use it we have
to make sure it's present in all the pieces of the interconnect model.
- I know Arpad had suggested using A_gnd as that N+1st node, but then is that
the only component that connects to A_gnd?
- If this N+1st reference node can be connected to a node outside of the
modeling area, then there must be no current through that node. That
terminal must be internally isolated from the rest of the terminals in
the component.
- Let's say you have a resistor that connects nodes 1 and 2, and you have a
node 3 that is isolated from the first 2. So you make a two-port model with
port 1 (nodes 1 and 3) and port 2 (nodes 2 and 3). This configuration
results in Z matrix non-existent, or Y matrix singular. Typical
S-parameter data in a Touchstone file has no such restriction.
- This is the problem. If you had some connection between nodes 1 and 3
or nodes 2 and 3 then you would get current flowing through node 3. The
only case when there's no current through node 3 is the one I just
described (above). If you have a configuration like that then you can
freely connect node 3 to any node (including node 0). But if you don't
obey this restriction then you get ambiguous results depending on what is
done elsewhere in the external circuit.
- Arpad: I'd like to hear a proposal to resolve this. I think we've gone over
the problem statement multiple times at recent meetings.
- Bob: I'm not sure it's fixable. Here's a problem: If one of the package
models uses node 0 as its reference, and it's cascaded with a second
package model that uses one of the traces as its reference, then you have
an incompatibility.
- We can just advise about this with a warning in the spec.
- That second model might be an IBIS-ISS model with a node 0 reference.
- Arpad: This situation reminds me of the referencing discussions related to
the [Pullup Reference], [Pulldown Reference], etc. We discussed node 0
in that context too.
- It sounds like Radek's concern is that if one of the interconnect models
touches node 0 and nothing else in the circuit does, then you'd have a
portion of the circuit disconnected from another portion.
- Radek: Exactly, that's the origin of the problem.
- Arpad: In IBIS, at least one of the voltage sources that supplies the I/V
curve based buffer will most likely be connected to node 0. I don't
know of any simulators that can do things without have the common
reference somewhere.
- Radek: There's a consequence of the fact that File_TS0 is forcing a connection
to node 0, because you're not necessarily connecting that node 0
anywhere else in the simulation.
- Arpad: Doesn't that problem exist elsewhere in the spec., too?
- What if someone uses A_gnd in [External Model], couldn't you have the same
argument?
- I'm not sure this is the place to fix this issue. Would we have to rewrite
the whole spec?
- Radek: If we use the text I emailed out (included in last week's minutes),
that's a clear statement to tool and model makers of the issue and
restrictions.
- If we say nothing we are hiding our heads in the sand.
- People won't always know what they're doing if we don't give them any
warning.
- Originally IBIS was constructed around node 0.
- [Voltage Range] was specified between global ground and the pullup_ref,
for example.
- We have moved on from that a bit and are now talking about PDNs and pins
that are connected. We have editorial work on cleaning up the referencing
issues. We've been working on that and it is not finalized.
- This File_TS0 would be trying to enforce a mechanism that runs counter to
these updates.
- We have the same issue with an IBIS-ISS model that might include a
connection to node 0 internally.
- Arpad: I'm still not sure this is the place to address this.
- In SPICE type simulators, if your netlist is never touching node 0 then you
get a "no DC path to ground" warning.
- So there's already an implicit expectation of one node somewhere being
related to node 0.
- Radek: You wouldn't arbitrarily take one terminal of your circuit and connect
it to a totally different location and expect the results to stay the
same. But we are trying to give designers a way to do it without
mentioning that this could be incorrect.
- Arpad: Say you have a mother board design and you're going out of your way to
model all the power and ground planes. So none of your buffers is
connected to node 0, they're all connected to your non-ideal planes.
At some point, no matter what you do, the VRM model or some other
source ends up tied back to node 0.
- If that connection to node 0 already exists somewhere in the circuit, is
this really an issue?
- Radek: Yes, the issue is that you cannot arbitrarily grab one terminal and
connect it to some outside circuitry, and that's what this is trying
to do.
- Only if it's known and enforced that there is no current flowing under all
possible external connections, then you can freely connect it anywhere.
- Bob: Radek raises the flag.
- But going in the other direction, we could have everything specified
relative to local references, with no node 0 declared in the modeling area
([Model], on-die interconnect, package), and Arpad is pointing out that
some VRM somewhere would be hooking up the rail terminals with respect to
a reference ground. But anywhere else along the path being simulated could
be floating, and any place along that path where you hard code a connection
to node zero could be corrupting the path.
- Radek: Your scenario would be a good place not to use File_TS0. Use the
File_TS and the N+1st is one of the terminals in the modeling area.
- Discussion: The group discussed two different scenarios. Arpad proposed an
example of a two port transmission line's S-parameter data. He said that
could be the same as an ideal transformer with two independent coils connected
across the two ports (2N case, independent references). He asked if you then
go to common reference (N+1 case) don't you have the information needed to
model the voltage relationships between port 1 and port 2? Radek said it was
a mistake to assume such a model could give you the voltage information you
needed without any regard for where the reference terminal were connected.
Bob said he was concerned about the validity of Radek's proposed restriction
text. Bob proposed a one port example in which a resistor was connected
between terminal 1 and the reference terminal. He said current would indeed
flow to node 0 if that were the reference terminal. Radek said this example
illustrated the problem. One could not expect to connect the reference
terminal to any arbitrary location without affecting the results, unless the
resistor's value was infinite (reference terminal isolated from terminal 1).
Radek said this situation could be modeled as a two port, with the resistor
connecting terminals 1 and 2 and the third terminal a common reference and
isolated from the first two. This configuration would meet the requirements
of Radek's proposed restriction text.
- Arpad: Can we fix this issue with a statement about something that the model
maker should be aware of? I agree with Bob that whether it's node 0
or some other reference node the constraints should be the same.
- Radek: My text is a precise statement of the restriction on the Touchstone
data used with File_TS0.
- Arpad: Thank you all for joining.
AR: Arpad to submit BIRD165.1 to the Open Forum.
-------------
Next meeting: 21 November 2017 12:00pm PT
-------------
IBIS Interconnect SPICE Wish List:
1) Simulator directives
