Bob,
I think we want to support the following example:
20 VDD pins
10 VDD pads
50 Buffers with VDD as PUref
A package model for VDD that has 30 terminals, 20 pins and 10 pads.
An on-die model for VDD that has 60 terminals, 10 die pads and 50 PUref.
Walter
From: ibis-interconn-bounce@xxxxxxxxxxxxx
[mailto:ibis-interconn-bounce@xxxxxxxxxxxxx] On Behalf Of Bob Ross
Sent: Sunday, August 23, 2015 2:42 PM
To: 'IBIS-Interconnect' <ibis-interconn@xxxxxxxxxxxxx>
Subject: [ibis-interconn] Re: Interconnect BIRD Terminal Section Rewritten
Walter,
Looking at the table, and according to your rules, it make no sense to
even declare pad_names for Pad_rail. These names cannot be connected to
anything using pad_name.
It is technically and syntactically possible use the same pad_name to
declare a group of pads that are connected on the die and to have that
group treated as distinct from another group of pads with another
pad_name. Therefore Buffer_Rail pad_name should support this for higher
resolution, more accurate interconnect models.
Otherwise [Die Supply Pads] declarations are useless.
Bob
From: <mailto:ibis-interconn-bounce@xxxxxxxxxxxxx>
ibis-interconn-bounce@xxxxxxxxxxxxx [
<mailto:ibis-interconn-bounce@xxxxxxxxxxxxx>
mailto:ibis-interconn-bounce@xxxxxxxxxxxxx] On Behalf Of Walter Katz
Sent: Sunday, August 23, 2015 5:24 AM
To: IBIS-Interconnect
Subject: [ibis-interconn] Re: Interconnect BIRD Terminal Section Rewritten
Bob,
If you want VDD1 to connect to one set of buffers, and VDD2 to connect to
another set of buffers then you would need to pull out terminals for each
buffer, and therefore use PUref (or PCref) with pin_name.
As I tried to explain in the document:
The model of an I/O Buffer has supply terminals in addition to the
Buffer_I/O. These supply (or rail) terminals can be PUref, PDref, PCref,
GCref and/or EXTref. These terminals can be connected to interconnect
models one of two ways:
1. By specifying a unique interconnect terminal for each I/O Buffer
PUref, PDref, PCref, GCref and/or EXTref
2. By assuming that all I/O Buffer supply terminals connected to a
supply signal_name are shorted together. This is done by specifying a
unique terminal for all I/O Buffer terminals that are connected to a
specific signal_name on at least one Supply Pin.
Since you clearly describing the case where the model make does not want
to assume all Buffer rails on a specific signal_name are shorted together,
then the model make need to use PUref (or PCref) with pin_name.
So it therefore makes no sense to associate Buffer_Rail with anything
other than signal_name.
Walter
From: ibis-interconn-bounce@xxxxxxxxxxxxx
<mailto:ibis-interconn-bounce@xxxxxxxxxxxxx>
[mailto:ibis-interconn-bounce@xxxxxxxxxxxxx] On Behalf Of Bob Ross
Sent: Saturday, August 22, 2015 7:45 PM
To: 'IBIS-Interconnect' <ibis-interconn@xxxxxxxxxxxxx
<mailto:ibis-interconn@xxxxxxxxxxxxx> >
Subject: [ibis-interconn] Re: Interconnect BIRD Terminal Section Rewritten
Walter,
Ok, I will accept this.
However, we should also add pad_name as an acceptable designator
for Buffer_rail so that distinct power nodes for the same VDD in buffers
can be connected
to unique pad_names (e.g., VDD1, VDD2), assuming the interconnect IBIS-ISS
or Touchstone
file has circuit to connect VDD to VDD1 and VDD2. We would also have
files to connect
VDD1 to one set of buffers and VDD2 to another set.
So, I would amend the table
From:
Terminal_Type
pin_name
signal_name
pad_name
Aggressor
Buffer_I/O
X
X
Puref
X
Pdref
X
Pcref
X
Gcref
X
EXTref
X
Buffer_Rail
Y
Pad_I/O
X
Pad_rail
Y
Z
Pin_I/O
X
Pin_rail
Y
Y
To:
Terminal_Type
pin_name
signal_name
pad_name
Aggressor
Buffer_I/O
X
X
Puref
X
Pdref
X
Pcref
X
Gcref
X
EXTref
X
Buffer_rail
Y
Z
Pad_I/O
X
Pad_rail
Y
Z
Pin_I/O
X
Pin_rail
Y
Y
Bob
From: <mailto:ibis-interconn-bounce@xxxxxxxxxxxxx>
ibis-interconn-bounce@xxxxxxxxxxxxx [
<mailto:ibis-interconn-bounce@xxxxxxxxxxxxx>
mailto:ibis-interconn-bounce@xxxxxxxxxxxxx] On Behalf Of Walter Katz
Sent: Thursday, August 20, 2015 12:49 PM
To: IBIS-Interconnect
Subject: [ibis-interconn] Re: Interconnect BIRD Terminal Section Rewritten
Bob,
The first part of your response is editorial, and I will leave that for
others to decide.
I object to the second part of your response (relating to signal_name). I
think it is commonly accepted that if a data book says that 10 pins have a
data book name of VDD, then VDD is connected through a low impedance
voltage distribution system on the chip and this voltage distribution is
the rail voltage supplied to a number of I/O buffers. Is this not correct?
Walter
From: ibis-interconn-bounce@xxxxxxxxxxxxx
<mailto:ibis-interconn-bounce@xxxxxxxxxxxxx>
[mailto:ibis-interconn-bounce@xxxxxxxxxxxxx] On Behalf Of Bob Ross
Sent: Thursday, August 20, 2015 2:50 PM
To: 'IBIS-Interconnect' <ibis-interconn@xxxxxxxxxxxxx
<mailto:ibis-interconn@xxxxxxxxxxxxx> >
Subject: [ibis-interconn] Re: Interconnect BIRD Terminal Section Rewritten
All,
Good start. I am not yet going to comment on the write-up details.
Regarding terminology, initially I had some concern about "Buffer_I/O" as
being too restrictive. Even though "IBIS" is the abbreviation for "I/O
Buffer Interface Specification," the Termination and Series and
Series_switch Model_types were added in Version 2.1 and later.
So I would add a foot note under the table to clarify that "Buffer_I/O"
and the "_I/O" extension refers to the node/port associated with any legal
IBIS [Model] Model_type.
The table is good. I would re-insert the foot notes regarding X, Y, and Z
for brevity of the rules.
--
After looking at the table, I am re-raising the issue that we should NOT
allow signal_name for Pad_rail. "signal_name" is directly associated with
[Pin], and therefore should be used only with the [Pin] location, as in
this example:
1 Buffer_I/O pin_name A1
2 Buffer_I/O pin_name A2
3 Puref pin_name A1
4 Puref pin_name A2
5 Pad_rail pad_name VDD1 | Assume
this connects to the A1 Buffer
6 Pad_rail pad_name VDD2 | Assume
this connects to the A2 Buffer
7 Pin_rail signal_name VDD
If we use Pad_rail signal_names, we lose documentation information
concerning which pad is connected to which Puref, and which interconnect
structure is connected from Pin to Pad. Some EDA tools may implicitly
short the pad side of the documented interconnect structure:
5 Pad_rail signal_name VDD |
Existing Pad to Buffer connections are ambiguous
6 Pad_rail signal_name VDD
7 Pin_rail signal_name VDD
If we want to support direct Pin to Buffer connect structures (by-passing
different pads), then Pin_rail signal_name is available and clear.:
5 Pin_rail signal_name VDD
So Pad_rail should not allow signal_name because of documentation and
possible connection confusion.
--
However, we should consider allowing Buffer_rail to support pad_name for
on-die rail "busses" that are connected to distinct pads (versus just
shorted paths to just signal_names).
Bob
From: <mailto:ibis-interconn-bounce@xxxxxxxxxxxxx>
ibis-interconn-bounce@xxxxxxxxxxxxx [
<mailto:ibis-interconn-bounce@xxxxxxxxxxxxx>
mailto:ibis-interconn-bounce@xxxxxxxxxxxxx] On Behalf Of Walter Katz
Sent: Wednesday, August 19, 2015 9:06 PM
To: 'IBIS-Interconnect'
Subject: [ibis-interconn] Interconnect BIRD Terminal Section Rewritten
All,
This is a first cut at rewriting the Terminal section to reflect the
discussion we had at today's meeting
Walter
Walter Katz
<mailto:wkatz@xxxxxxxxxx> wkatz@xxxxxxxxxx
Phone 303.449-2308
Mobile 303.335-6156
