[ibis-macro] Re: Draft reference warning text (was The Mystery Component)
- From: "Muranyi, Arpad" <Arpad_Muranyi@xxxxxxxxxx>
- To: "ibis-interconn@xxxxxxxxxxxxx" <ibis-interconn@xxxxxxxxxxxxx>, "ibis-macro@xxxxxxxxxxxxx" <ibis-macro@xxxxxxxxxxxxx>
- Date: Fri, 13 Apr 2018 05:26:33 +0000
Hello Everyone,
I think I am starting to understand what Radek is trying to say. Let me give
it a try to explain
it with my words.
First, let me ask a "trick question". Let me start with a picture. Here is a
drawing for a package
model, which has five lines, two for "power", two for "ground" and one for
"signal":
[cid:image002.png@01D3D2AF.6E3C6D40]
Using IBIS-ISS, we would declare the subcircuit definition line as follows:
.subckt Vdd1 Vdd2 IO_pin Vss1 Vss2 PC_ref PU_ref IO_pad PD_ref GC_ref
...
...
.ends
Now comes the trick question: How many terminals would we say does this
subcircuit have?
Most of us would say, count the terminals on the .subckt line, you get 10. But
Radek is trying to
tell us that this subcircuit has 11 terminals, because there is a connection to
node 0 inside, and
because node 0 is a global node, it touches everything on the outside of the
subcircuit, therefore
it acts the same way as any other terminal on the subcircuit declaration line
(even if it is not
listed there).
Now, Radek is not saying that the EDA tool should change anything in the
netlist by adding the
11th terminal to the .subckt line and connect the internal node 0 to it from
the inside, and then
propagate this "extra" terminal up through the rest of the netlist hierarchy.
I think what Radek
is saying is that whatever environment this subcircuit appears in should be
aware of that undeclared
additional "terminal" (the connection to node 0 on the inside) and do things
accordingly when
making connections to this subcircuit from the outside, AS IF this extra
terminal existed on the
subcircuit definition line. But this is what needs the explanation, because I
am not sure how
many of us really understand what this means. Here is how I would explain it:
Imagine that the above package is now mounted on a printed circuit board, on
which we have a
5-conductor W-element connected to its pins, like this:
[cid:image001.png@01D3D2B0.2D3C9B20]
Note that the reference terminal of the PCB W-element is also connected to node
0. This is the
only correct way to connect that W-element on the PCB with the package model's
subcircuit.
I think what Radek is saying is that conceptually these two reference terminals
are now connected
through this (undeclared) "extra terminal" of that package subcircuit. When
Radek uses the words
"treat it as", I think he means that (without adding an additional subcircuit
terminal) the user (or EDA
tool?) should make sure that whatever is connected to this subcircuit on the
PCB side is aware of
this undeclared extra terminal and make sure that the stuff on the PCB and the
subcircuit is hooked
up correctly with that in mind. This is the same AS IF the EDA tool or the
model maker would have
done any of the following through an explicitly declared 11th subcircuit
terminal:
[cid:image003.png@01D3D2B1.6393EEC0]
[cid:image004.png@01D3D2B4.1457C900]
So this "Important" statement in BIRD189 is an attempt to alert the reader that
if the
subcircuit has a connection to node 0 on the inside, than whatever else is on
its outside
should consider at least one connection to node 0 as well in order to be able
to account
for the voltages and currents between the various circuit elements correctly.
Radek, is my interpretation of your intent correct?
Everyone, does this start making sense now?
Assuming (and hoping) that my explanation above is what Radek has in mind, I
need to make a
comment right away. This is all nice and dandy, but what happens if the node 0
connection inside
the subcircuit is used for other than referencing W-elements or S-parameter
elements? Randy's
package model example comes to my mind, which I believe intended to do
something like this
(with discrete elements instead of the W-element shown here):
[cid:image006.png@01D3D2BD.1E0C4990]
While Randy said that those capacitors to node 0 were negligible and could be
shorted by connecting
the reference node of the interconnect model (W-element in this drawing) to
node 0, this information
is not necessarily available from the model in an automatable form. What if
there are real reasons for
NOT shorting them to node 0? How is the user or EDA tool going to know what
the proper connections
are in general? This example could probably be extended in many different
directions, not just using
the W-element reference terminals...
The point I am trying to make is that even if we found the perfect words to
write a warning about the
above conditions, I am not sure what the end user or EDA tool can do about it
(automatically). The
only person who CAN do something about that is the model maker, by NOT making
"bad" models.
But then we need to define rules for what constitutes a "bad" model to help the
model maker to
make "good" models... Any ideas / suggestions?
Thanks,
Arpad
===============================================================================
From: ibis-interconn-bounce@xxxxxxxxxxxxx
[mailto:ibis-interconn-bounce@xxxxxxxxxxxxx] On Behalf Of ;
radek_biernacki@xxxxxxxxxxxx
Sent: Thursday, April 12, 2018 2:14 PM
To: michael.mirmak@xxxxxxxxx; ibis-interconn@xxxxxxxxxxxxx
Subject: [ibis-interconn] Re: Draft reference warning text (was The Mystery
Component)
Hi Michael,
Thanks. The following are my comments on the questions and suggestions.
1. I think we do not need to soften it anymore because we really want to
alert the model maker and the user about possibly incorrect results. I have
already phrased it as "may be incorrect". In making a statement of being "less
accurate" the question is what the reference for "less" is.
2. The alternative text confuses the issue even more. My statement intended
to state that the global ground node is an additional node for the connection
to the external world. Using your example the external nodes are then 2, 4, and
the ground node. This is not netlisted. The only netlisted nodes are those
specified in the terminal lines in the instantiation of File_TS or File_ISS.
And of course all the nodes down the hierarchy inside of the ISS subcircuit,
including any global ground node. There is nothing we would require the
simulation tool to assume or to make its calculations, nor to netlist, except
for passing a warning to the user in any way chosen by the EDA tool. This is
for the user to appropriately connect the external circuitry to all the
external terminals of the buffer (at the pin interface) where that set of
external terminals is de-facto augmented by the ground node.
3. No. In your example I said "No, Terminal 4 is not in any way special to
connect it to A_gnd by definition". This does not exclude the possibility of
grounding of any of the "normal" terminals because of some other
considerations, e.g., grounding the Pulldown_ref node if [Pulldown Reference]
is zero and the EDA tool operates that way.
Regarding 3, we can and still need to have a separate statement on what to do
with the rail terminals for BIRD 158.
Radek
From: Mirmak, Michael [mailto:michael.mirmak@xxxxxxxxx]
Sent: Wednesday, April 11, 2018 9:43 AM
To: BIERNACKI,RADEK (K-Sonoma,ex1)
<radek_biernacki@xxxxxxxxxxxx<mailto:radek_biernacki@xxxxxxxxxxxx>>;
ibis-interconn@xxxxxxxxxxxxx<mailto:ibis-interconn@xxxxxxxxxxxxx>
Subject: Draft reference warning text (was The Mystery Component)
Radek,
Thanks for the response and suggested text. Today's Interconnect Task Group
generally liked your updated text but had two questions and a suggestion:
1) Would the phrase "may be less accurate" be acceptable as an alternative
to "may be incorrect"?
2) The phrase "shall be treated as" caused some confusion. Simply put,
does this mean that the simulator will actually change the netlist to add the
new terminal at the pin interface, in a way the user would see in the netlist?
Or instead, do only the loop calculations used by the simulator change? The
statement itself leaves this open, but your commentary below strongly suggests
that the netlist must change.
3) Finally, is the order of the phrasing what you intended? Instead of
"the global reference node shall be treated as one of the terminals of the
buffer at the pin interface", was the intent to say "one of the terminals of
the buffer at the pin interface may be connected (shorted) to the global
reference node"?
An alternative that addresses all of the above would be:
Warning: If the IBIS-ISS ground node (0, GND, !GND, GND!, or GROUND) is used
anywhere in the subcircuit hierarchy of File_ISS, or the node A_gnd is used as
a terminal in the [Interconnect Model], the simulation tool shall assume and
make its calculations as if the global reference node is present as an
additional terminal of the buffer at the pin interface (this may not be visible
in the netlist presented to the simulation tool user). This, in general, may
require a return path to the buffer from the external circuitry to pass
thorough the global reference node, and if that condition is not met, the
simulation results may less accurate.
Thanks again!
- MM
From: radek_biernacki@xxxxxxxxxxxx<mailto:radek_biernacki@xxxxxxxxxxxx>
[mailto:radek_biernacki@xxxxxxxxxxxx]
Sent: Wednesday, April 11, 2018 12:17 AM
To: Mirmak, Michael
<michael.mirmak@xxxxxxxxx<mailto:michael.mirmak@xxxxxxxxx>>;
ibis-interconn@xxxxxxxxxxxxx<mailto:ibis-interconn@xxxxxxxxxxxxx>
Subject: RE: The Mystery Component
Hi Michael,
1. For the highlighted text, the task is for the parser/EDA tool to inform
the user about it, and for the spec to alert both the model maker and the user
about the need to treat A_gnd as an additional terminal of the buffer model.
2. [Pin], and yes.
All,
As I will not be able to join the meeting today, the following is the proposed
reformulation of the two "Important" paragraphs. I propose to replace the two
paragraphs
Important: When Terminal_type A_gnd is used then the A_gnd node shall be used
as the reference node for the I/O signal port(s) associated with the
Interconnect Model.
Important: If a global reference (e.g., SPICE node 0) is used inside of an
IBIS-ISS subcircuit, it shall be treated as the A_gnd node but with the
additional requirement that the EDA tool connect it to the tool's global
reference.
with
Warning: If the IBIS-ISS ground node (0, GND, !GND, GND!, or GROUND) is used
anywhere in the subcircuit hierarchy of File_ISS, or the node A_gnd is used as
a terminal in the [Interconnect Model], the global reference node shall be
treated as one of the terminals of the buffer at the pin interface. This, in
general, may require a return path to the buffer from the external circuitry to
pass thorough the global reference node and if that condition is not met the
simulation results may be incorrect.
Originally, I proposed the first paragraph in the context of A_gnd being a
"local" ground. Since A_gnd is now the global ground there is no need to have
two cases anymore. I also believe there is no need to distinguish power-aware
from non-power-aware simulations as the issue affects both in a similar way.
Radek
From: Mirmak, Michael [mailto:michael.mirmak@xxxxxxxxx]
Sent: Tuesday, April 10, 2018 11:55 AM
To: BIERNACKI,RADEK (K-Sonoma,ex1)
<radek_biernacki@xxxxxxxxxxxx<mailto:radek_biernacki@xxxxxxxxxxxx>>;
ibis-interconn@xxxxxxxxxxxxx<mailto:ibis-interconn@xxxxxxxxxxxxx>
Subject: RE: The Mystery Component
Radek,
Thank you! To clarify, my final question should have been broken into two, and
I believe you answered both. To summarize, if the "Bad Circuit" were the
package for a two-terminal device, with Terminals 2 and 4 connected to the
outside world as [Pin]s on a [Component], then the proposal is to add or assume
a fifth terminal, A_gnd, because the Bad Circuit contains an ideal node 0
connection that is not declared as part of the subcircuit definition.
I just have two remaining concerns:
1) You state that the proposal is to "ensure that A_gnd is treated as an
additional node" - is this treatment to be enforced on the model-maker or is it
something that the EDA tool would be expected to implement? In other words,
would we parse interconnect subcircuits for ideal node 0 content, then reject
any that didn't use the additional A_gnd terminal in the subcircuit definition?
Or would we simply expect EDA tools to instantiate any models containing ideal
node 0 as having an additional terminal, A_gnd? The latter may be easy to
state in the specification and may already be done in some cases; the former
may encounter... resistance.
2) Does this extend only to the [Model] level, or does it extend all the
way to [Pin]? In other words, will the presence of ideal node 0 inside any
part of a [Component] drive the creation/assumption of an A_gnd "pin"?
Thanks again!
- MM
From: radek_biernacki@xxxxxxxxxxxx<mailto:radek_biernacki@xxxxxxxxxxxx>
[mailto:radek_biernacki@xxxxxxxxxxxx]
Sent: Monday, April 09, 2018 12:16 PM
To: Mirmak, Michael
<michael.mirmak@xxxxxxxxx<mailto:michael.mirmak@xxxxxxxxx>>;
ibis-interconn@xxxxxxxxxxxxx<mailto:ibis-interconn@xxxxxxxxxxxxx>
Subject: RE: The Mystery Component
Hi Michael,
Thanks, and yes, you have illustrated the situation right.
First, the "Bad" circuit is not necessarily bad. It may be undesired but if it
is defined that way there are consequences of such a definition.
The following are my comments/additions to the questions you raised in the
final slide.
* Yes, for this specific example. In general, however, no. It depends on
where inside of the subcircuit the connection to ground is present.
* The Bad circuit is already legal in IBIS-ISS spec. And, there already
exist models using the connections to the global ground inside of the
subcircuits. Furthermore, it is conceivable (though not really advisable, nor
enforceable) to rework the subcircuit definition to have the fifth terminal
(e.g., 1 2 3 4 5) added, and then instantiated as "Xmystery_component_1 1 2
3 4 A_gnd mystery_component". However, if this is inside of File_ISS, it
does not solve the issue, just brings it to the [Model] level in the circuit
hierarchy.
* No, Terminal 4 is not in any way special to connect it to A_gnd by
definition. The proposal is to ensure that A_gnd is treated as an additional
node to connect the overall buffer to the external world, and specifically as
the reference node in the I/O port. That's really consistent with the legacy
IBIS "ground-based" modeling.
Radek
From:
ibis-interconn-bounce@xxxxxxxxxxxxx<mailto:ibis-interconn-bounce@xxxxxxxxxxxxx>
[mailto:ibis-interconn-bounce@xxxxxxxxxxxxx] On Behalf Of Mirmak, Michael
Sent: Friday, April 6, 2018 3:25 PM
To: IBIS-Interconnect
(ibis-interconn@xxxxxxxxxxxxx<mailto:ibis-interconn@xxxxxxxxxxxxx>)
<ibis-interconn@xxxxxxxxxxxxx<mailto:ibis-interconn@xxxxxxxxxxxxx>>
Subject: [ibis-interconn] The Mystery Component
Per today's IBIS Interconnect discussion, I assembled the enclosed three slides
(plus title slide) to illustrate what I believe Radek's proposal is, and the
situation we are trying to address. Note that neither W-elements nor
Touchstone structures are used.
Some simple questions are raised on the final slide. Comments and questions in
return are welcome.
- MM
Other related posts:
- » [ibis-macro] Re: Draft reference warning text (was The Mystery Component) - Muranyi, Arpad
