Arpad and I worked on a draft 1 of BIRD189.5, based on his review comments.
The attached document contains both outright changes and a few comments for
group discussion. All prior markup was accepted.
Hopefully we can schedule a discussion meeting, probably of the Interconnect
Task group.
Mike
From: ibis-editorial-bounce@xxxxxxxxxxxxx
[mailto:ibis-editorial-bounce@xxxxxxxxxxxxx] On Behalf Of Muranyi, Arpad
Sent: Wednesday, July 5, 2017 12:56 PM
To: ibis-editorial@xxxxxxxxxxxxx
Subject: [ibis-editorial] Re: Comments on BIRD189.4
To speed things up, I was hoping that Mike and I could get together on the
phone to write a draft and then discuss it in a meeting to approve or make
further changes if necessary.
Arpad
==========================================================
From: Bob Ross [ <mailto:bob@xxxxxxxxxxxxxxxxx>
mailto:bob@xxxxxxxxxxxxxxxxx]
Sent: Wednesday, July 5, 2017 11:54 AM
To: Muranyi, Arpad < <mailto:Arpad_Muranyi@xxxxxxxxxx>
Arpad_Muranyi@xxxxxxxxxx>; <mailto:ibis-editorial@xxxxxxxxxxxxx>
ibis-editorial@xxxxxxxxxxxxx
Subject: RE: [ibis-editorial] Re: Comments on BIRD189.4
All,
I think the comments are good, but we should hold an “Interconnect Meeting”
meeting next week to review them … leading to BIRD189.5.
Bob
From: <mailto:ibis-editorial-bounce@xxxxxxxxxxxxx>
ibis-editorial-bounce@xxxxxxxxxxxxx [
<mailto:ibis-editorial-bounce@xxxxxxxxxxxxx>
mailto:ibis-editorial-bounce@xxxxxxxxxxxxx] On Behalf Of Muranyi, Arpad
Sent: Wednesday, July 5, 2017 9:44 AM
To: <mailto:ibis-editorial@xxxxxxxxxxxxx> ibis-editorial@xxxxxxxxxxxxx
Subject: [ibis-editorial] Re: Comments on BIRD189.4
Mike,
Thanks for your responses. Are you the gatekeeper of the document? If so,
would you like to get together on the phone and generate a new rev with
these modifications?
Regarding example 4, and your comment “I see nothing in example 4 calling
for any buffer to be connected to VSS.” let me try to explain my question
again.
Put yourself in the place of the EDA tool, parsing the .ibs file which
contains
the examples. When you parse example 1, everything seems to be well
defined,
all 29 terminals have a clearly defined connection using the pin names.
This
implies that the connections defined in [Pin Mapping] with the legacy syntax
for the same buffers should be ignored.
Example 2 is still clear in this regard, because it seems to describe a
clear path
for the power connections between the pin rails and buffer rails.
Example 3 uses a 2 port Touchstone model to connect the signal pin with the
buffer’s signal terminal. The N+1 reference terminal of the Touchstone file
is connected to the Pulldown_ref terminal of the buffer. This is still
clear.
However, note that in this example does not describe any power supply
connections between the buffer and the pins, so the buffer will need to get
its power through the definitions described in [Pin Mapping] and legacy
package
model.
Now, look at example 4. In this example we are still describing only the
signal
pin to buffer signal terminal path. This example uses two interconnect
model
segments, one of which is referenced to the Pulldown_ref terminal of the
buffer, and the other one is referenced to the VSS signal name of the [Pin]
keyword. How would the EDA tool’s parser know that these interconnect
models are not providing a current carrying path between the VSS pin rail
and
the Pulldown_ref terminal of the buffer?
Thanks,
Arpad
==============================================================
From: Mike LaBonte [ <mailto:mlabonte@xxxxxxxxxx>
mailto:mlabonte@xxxxxxxxxx]
Sent: Wednesday, July 5, 2017 8:03 AM
To: Muranyi, Arpad < <mailto:Arpad_Muranyi@xxxxxxxxxx>
Arpad_Muranyi@xxxxxxxxxx>
Cc: <mailto:ibis-editorial@xxxxxxxxxxxxx> ibis-editorial@xxxxxxxxxxxxx
Subject: Re: [ibis-editorial] Comments on BIRD189.4
Thanks Arpad, my notes are inline:
pg. 5 Bad English:
“All Interconnect Model Sets exist for the component shall be listed in this
section.”
Mike: We could go with either "that exist" or "existing", but I prefer the
former.
pg. 5 The first “ibs” should be “ims”:
“The files containing the Interconnect Model Sets with the ibs extension
shall be located in the same directory as the .ibs file”
Mike: Hmmm, two ways of decribing files by extension in the same sentence.
Why isn't this:
“The .ims files shall be located in the same directory as the .ibs file”
The [Bus Label] section is a little fuzzy to me. As I am reading the
“Description” I
get the question, where is a “bus_label” defined? Searching the v6.1 spec
for
“bus_label” returned four occurrences in the [Pin Mapping] section. But the
last
sentence of the usage rules here says “A bus_label may be defined also by
the
[Pin Mapping] keyword.”, which seems to imply that this keyword ([Bus
Label]) is
used to define “bus_label”. If so, the description should say something
along the
lines of (text in red added):
“Defines bus_label names and associates a POWER or GND signal_name with one
or more bus_label names within a Component.”
Mike: IBIS 6.1 does not have "bus_label" anywhere, but it has "bus label" in
four places. BIRD 182 was the first to use "bus_label", then 185 and 189. I
think "bus label" is explained well enough in IBIS 61,so maybe we should
stick with that, except where we are explicitly referring to a column
heading (as in "bus_label column").
I also wonder what the word “terminal” means in this sentence (pg. 7):
“The bus_label names can be used to define terminals at the buffer, die pad
or pin interfaces.”
If I understand it correctly, buffer models have terminals and interconnect
models
have terminals. The connection between them (and other things) are achieved
through
nodes. Pads, bumps, pins, balls usually serve as a node for making such
connections.
So with that in mind, I wonder what is “terminals at a buffer, pad, or pin
interfaces”
refer to? What are we trying to say by “The bus_label names can be used to
define
terminals”?
Later, on pg. 23 we say:
“…determines if the terminal is at a pin, die pad or buffer” which seems to
say that
the terminals of the interconnects can be connected to the pin, pad or
buffer.
So talking about defining terminals at pin/pad/buffer doesn’t seem to make
sense
to me… As far as I can tell, we might be defining what these various
terminals are
connected to, but we are not defining the terminals themselves…
Mike: I agree that "terminals" probably is not used correctly here, and I
don't know what the sentence means.
pg. 7 Bad English:
“Associates signal_names and bus_labels to die pads”
Don’t we associate things with (or assign/connect things to) other things?
Mike: Agree.
I have a similar question/concern about the [Die Supply Pads] keyword.
Where
are die pads defined? The description of this keyword only says that this
keyword “associates”… Yet, reading between the lines, it seems that this
keyword is actually used to define the die pad names in addition to
associating
them with those other things. If so, shouldn’t this description say
something
along the lines of:
“Defines pad names and associates signal_names and bus_labels with die pads
connected to supply rails.”?
Also, since this keyword is functionally almost equivalent to the [Node
Declarations]
keyword, I think we should say something about whether they are mutually
exclusive,
or allowed together? We do say that “Note that [External Circuit] and
[Interconnect
Model Set Selector] shall not be present within the same [Component]”, but
we
don’t say anything about [Node Declarations]…
Mike: I think the section for [Node Declarations] clearly associates it with
the [Circuit Call] keyword. However, searching for "die pad" will lead to
that section, and people might be confused. Maybe that section could say
that [Node Declarations] is only used for [External Circuit] and [Circuit
Call].
I have a problem with the following sentence in the introduction in chapter
12.1 (pg. 10):
“These interconnect models may include descriptions of interconnect coupling
and/or interconnect rail distributions.”
What is an “interconnect rail”? I think this refers to “power supply rail”…
We use
the word “rail” quite often throughout the document (without saying “power
supply
rail”) which to me seems to be a little bit “slang-ish”. I think an
official document
like this should be a little more formal and spell out “power supply rail”
for most
of the occurrences.
Also, this sentence mentions coupling, but doesn’t mention losses. If this
supposed
to be an overview of the capabilities, losses, especially frequency
dependent and
dielectric losses should also be mentioned, since they were not covered in
IBIS
before these features were added.
Mike: Agree on both points.
Related to the usage of “terminal” in the [Bus Label] keyword section (pg.
10):
“Interconnect is defined between up to three nodes, referred to here as
“terminals”:”
yet, in fig. 47 we only have buffer terminals (the die pads and pins are not
labeled as
terminals). (I remember a discussion on that in one of our meetings). This
seems a
little inconsistent (and perhaps confusing)…
But reading the rest of the document I think we are still quite inconsistent
about
how we use the word “terminal”. I think this can be confusing to a newbie
reading
this document. As far as I understand, buffer and interconnects have
terminals.
Die pads and pins are what those terminals are connected to, but a pad or a
pin is
NOT a terminal. We might call them a node to serve as a connection point,
but I
would never call them a terminal.
Then, consider the next sentence (pg. 11):
“The connection between the pin and die pad interface is generally called
“package interconnect”, while the connection between the die pad interface
and the buffer interface is generally called “on-die interconnect.” “
We are now referring to the same locations as “interface”, without defining
what “interface” really is. Do we really need so many different ways to
describe the same thing? I would suggest to call them the same way
consistently
throughout the entire document.
Mike: Terminals are the outward facing connection points for circuit
elements. When an element is instantiated its terminals are connected to
nodes of the circuit. We are used to thinking of buffers and transmission
lines as elements, but pads and pins are thought of only as nodes for the
t-lines to connect to. With BIRD 189 we have the concept of interconnect
subcircuit elements, which have terminals that can be connected to any of
the above. An interconnect model has terminals, and in that section we are
dividing those terminals into three "interfaces". So that description
probably needs work, and it might not need to use "nodes" at all.
I have a problem with the list of the interconnect model types (pg. 11):
* Uncoupled I/O connections
* Coupled I/O connections
* Rail connections
* Uncoupled or coupled IBIS-ISS connections
* Uncoupled or coupled Touchstone file connections
* Combinations of the above
The 4th and 5th bullets combine uncoupled and coupled, but the first two
bullets list them separately. For consistency, lets either list the first
two
bullets as one, or separate the 4th and 5th bullets into two each. Also,
what
is the difference between I/O connections, IBIS-ISS and Touchstone file
connections? Doesn’t IBIS-ISS and Touchstone give us the ability to
describe “I/O” as well as “Rail” connections? I just don’t see the
rationale
for this list as written.
Mike: We are mixing a list of interconnect model content types with a list
of things they can connect to. The entire "These may include" list may not
be necessary.
The word “Terminals” appears capitalized on the bottom of pg. 12 in mid
sentence. It should probably be lower case.
Mike: That one instance does stand out against many instances of "terminal"
and "terminals".
The following list would probably be more proper if we added the red words
(bottom of pg. 17):
* pin names and buffer terminal names (full package model)
* pin names and die pad names (package only model)
* or die pad names and buffer terminal names (on-die interconnect
model)
Mike: Not sure about this. These concepts are used without " names" in many
places.
I have seen “one or more than one” a couple of times, does this really
have to have the “than one” at the end? Wouldn’t it be simpler to just
say “one or more”?
What is a “simulation node” (pg. 18)? Wouldn’t it be sufficient to simply
say “node”?
Mike: If anything maybe "circuit node". It doesn't seem so bad in that place
to provide a reminder that nodes belong to circuits and terminals to
elements.
What is a floating voltage in this sentence (pg. 18)?
“However, this is not valid when the voltages of the ground nodes are
“floating”.”
Isn’t it the node that is floating (instead of the voltage)?
Mike: Agree, but are we OK with using "floating" in quotes without saying
what that means? Or should we say "without a path to Node 0"?
What is “GND” in the following sentence (pg. 19)?
“If this subparameter is present, the EDA tool should connect the unused
terminals to GND through a resistor”
Shouldn’t we say something like the reference node of the model?
Mike: We probably should be as nonrestrictive as possible here. So maybe
"some reference node" or possibly "connect the unused terminals to a node
having a DC path to Node 0".
The following sentences would probably be more appropriate with the added
words in red (pg. 25):
Any one pin name shall not be included in more than one terminal of an
Interconnect Model.
Any one die pad name shall not be included in more than one terminal of an
Interconnect Model.
Any one buffer terminal name shall not be included in more than one terminal
of an Interconnect Model.
Mike: Agree.
In fig. 52, do we have a reason to have the solid dots on each line at the
buffers?
We usually use these dots when there are more than two connections on a
point…
Or, if the intent is to emphasize that the buffer triangle has terminals at
its boundaries,
could we move the dots closer to the outline of the triangle (more or less
as it is
done for the signal line already)?
Mike: I would be OK with eliminating the dots.
Example 4 (pg. 31) seems to have the two file names reversed. The first
group
seems to deal with the interconnect between the pin and the pad, so the file
“dq_ts_buf_pad.s2p” which implies an interconnect between the pad and
the buffer seems to be out of place (and vice versa).
Mike: Agree.
Also I have a technical question about example 4. How would the EDA tool
know
whether this buffer is powered through the [Pin Mapping] mechanism, or
through
the interconnect models between the pins/pads/buffer terminals? Compare
this example with example 1, for which the same [Pin Mapping] keyword exists
in the .ibs file. In example 1, it is quite clear that the connections
described by
[Pin Mapping] should be ignored. But how do we know that for example 4? In
example 4 there is one terminal which is connected to VSS (which is a
bus_label
in the [Pin Mapping] keyword), and there is another terminal that is
connected
to the buffer’s Pulldown_ref. But how do we know whether the connection
from
VSS to Pulldown_ref is made by [Pin Mapping] or the interconnect model?
Mike: I see nothing in example 4 calling for any buffer to be connected to
VSS.
Sorry for the relatively large number of comments, better later than never…
Mike: That's OK as long as you don't send a bill ;-)
I hope we can fix most if not all of these easily…
Thanks,
Arpad
=================================================================
Attachment:
bird189.5_draft1.docx
Description: application/vnd.openxmlformats-officedocument.wordprocessingml.document
