[ibis-interconn] Re: The enclosed presentation graphically describes the Die Pad issue
- From: "Muranyi, Arpad" <Arpad_Muranyi@xxxxxxxxxx>
- To: 'Ibis-Interconn' <ibis-interconn@xxxxxxxxxxxxx>
- Date: Fri, 12 Oct 2012 13:39:28 +0000
Walter,
I don't think so...
I picked "999" for the buffer's pin as a random pin name
since you didn't define in your example how many buffers
the component has. I could have very well picked "xyz"
for that pin name... So in this example we are actually
talking about 201 lines with the one [Model] instance...
Once again, the question here is how much we want to retain
from the existing specification vs. invent new things. I
don't dispute that better, more efficient syntax could be
invented, but that goes in the directions of forking or
starting over from scratch. We need to decide how much of
that we want to get into vs. keeping what we already have.
Sincerely,
Arpad
===============================================================
From: ibis-interconn-bounce@xxxxxxxxxxxxx
[mailto:ibis-interconn-bounce@xxxxxxxxxxxxx] On Behalf Of Walter Katz
Sent: Friday, October 12, 2012 5:36 AM
To: 'Ibis-Interconn'
Subject: [ibis-interconn] Re: The enclosed presentation graphically describes
the Die Pad issue
Arpad,
Your example is exactly why using Pin_Mapping is the wrong thing to do.
Pin_Mapping adds 999 lines to the IBIS file, what I propose adds 4 lines to the
IBIS file with the same result.
Walter
From:
ibis-interconn-bounce@xxxxxxxxxxxxx<mailto:ibis-interconn-bounce@xxxxxxxxxxxxx>
[mailto:ibis-interconn-bounce@xxxxxxxxxxxxx]<mailto:[mailto:ibis-interconn-bounce@xxxxxxxxxxxxx]>
On Behalf Of Muranyi, Arpad
Sent: Thursday, October 11, 2012 11:42 PM
To: 'Ibis-Interconn'
Subject: [ibis-interconn] Re: The enclosed presentation graphically describes
the Die Pad issue
Walter,
What you describe below can be done with the existing [Pin Mapping] keyword
as shown below (actually two different ways, but I am only showing one).
The only new thing here would be the instantiation of the "IBIS_ISS_pkg_wrapper"
subcircuit which I deliberately left out from the example to avoid any
disputes on how that should be done. Of course if we want to stay away from
using the [Pin Mapping] keyword, we would need to come up with a new syntax...
But this is exactly the reason we need to decide how much we want to keep
from the existing specification, and how we see the "forking", i.e. new
directions for the specification. Why introduce something new if the old
thing works? Why keep the old thing when we hate it passionately?
[Pin] signal_name model_name R_pin L_pin C_pin
|
1 VDD POWER
2 VDD POWER
3 VDD POWER
...
...
100 VDD POWER
|
101 VSS GND
102 VSS GND
103 VSS GND
...
...
200 VSS GND
|
999 D0 I/O_buffer_model
[Pin Mapping] pulldown_ref pullup_ref gnd_clamp_ref power_clamp_ref ext_ref
|
1 NC PWRBUS1
2 NC PWRBUS1
3 NC PWRBUS1
...
...
100 NC PWRBUS1
|
101 GNDBUS1 NC
102 GNDBUS1 NC
103 GNDBUS1 NC
...
...
200 GNDBUS1 NC
|
999 GNDBUS1 PWRBUS1 GNDBUS1 PWRBUS1
*******************************************************************************
.SUBCKT IBIS_ISS_pkg_wrapper
+ Pin1 Pin2 Pin3 ... Pin100
+ Pin101 Pin102 Pin103 ... Pin200
+ PWRBUS1 GNDBUS1
+ TSFile="TouchstoneFileName.s1200p"
Spkg
+ Pin1 Pin2 Pin3 ... Pin100 * These are the 100 connections to the
VDD pins
+ Pin101 Pin102 Pin103 ... Pin200 * These are the 100 connections to the
VSS pins
+ PWRBUS1 PWRBUS1 PWRBUS1 ... PWRBUS1 * PWRBUS1 is repeated 500 times because
the
* package model has 500 ports for the
500 VDD
* die pads
+ GNDBUS1 GNDBUS1 GNDBUS1 ... GNDBUS1 * GNDBUS1 is repeated 500 times because
the
* package model has 500 ports for the
500 VSS
* die pads
+ MNAME=TSFile
+ [FBASE = base_frequency] [FMAX=maximum_frequency]
*******************************************************************************
.ends
Sincerely,
Arpad
=================================================================================
From:
ibis-interconn-bounce@xxxxxxxxxxxxx<mailto:ibis-interconn-bounce@xxxxxxxxxxxxx>
[mailto:ibis-interconn-bounce@xxxxxxxxxxxxx] On Behalf Of Walter Katz
Sent: Thursday, October 11, 2012 9:18 AM
To: 'Ibis-Interconn'
Subject: [ibis-interconn] Re: The enclosed presentation graphically describes
the Die Pad issue
Arpad,
You are trying to make something complicated that is really very simple. Let's
us take a common case of a component with 100 VSS pins, 100 VDD pins, 500 VDD
die pads and 500 VSS die pads. The IC Vendor assumes that the VDD die pads are
perfectly shorted and the VSS die pads are perfectly shorted, and delivers a
PDN IBIS-ISS subckt with 202 ports. Two of the ports being D_V1 and D_V1 on the
die. We are have legacy IBIS models IV/VT curves. In my proposal the [Model]s
require the following two keywords:
[PuRef] VDD
[PdRef] VSS
And [Die Pads] contain the following two records:
D_V1 VDD
D_V2 VSS
This PDN subckt port order in what I proposed in the ipkg file will use the
names D_V1 and D_V2. The [Model] instances will have their power and ground
correctly hooked up to VDD and VSS using ports D_V1 and D_V2 respectively
because they know D_V1 is VDD and D_V2 is VSS.
If there was no relationship between D_V1 is VDD and D_V2 is VSS, how would the
EDA tool know how to connect the supplies of the buffer to the ports of the PDN
package model.
Walter
Other related posts:
