[ibis-macro] Re: Updates to BIRD 145
- From: "Muranyi, Arpad" <Arpad_Muranyi@xxxxxxxxxx>
- To: 'IBIS-ATM' <ibis-macro@xxxxxxxxxxxxx>
- Date: Tue, 6 Mar 2012 19:12:25 +0000
Hello everyone,
I have been following these emails, but I was too
busy to reply. I am sensing that we are a little
bit mixing topics in these discussions, so I would
like to clarify a few things.
While BIRD 145 can help in defining better on-die
power delivery circuits, the same thing can also
be achieved with BIRD 116. The issue here is whether
we want to be able to cascade legacy [Model]-s with
[External Circuit]s or not.
Walter made a suggestion last week that we could
extend IBIS-ISS with the well-known HSPICE "B-element"
and if that is available in IBIS-ISS, we could just
place B-elements into [External Circuit]s using IBIS-ISS
which would eliminate the need to worry about the
complexities of cascading [Model] with [External Circuit].
This is a viable option we need to consider.
The other question Walter raised was regarding how the
EDA tool would know whether or not to apply power to
a [Model] whose reserved power and GND ports are now
connected to an on-die node to an [External Circuit].
The way BIRD 145 was written, it was not clear whether
the power was going into the [External Circuit] or
coming out of the [External Circuit]. We discussed
a few assumptions and rules in the last ATM teleconference,
but I didn't check yet whether any of that was captured
in the latest version of BIRD 145 which was uploaded to
the IBIS BIRD-s website a day or so ago.
What we need to do is compare the various ways of
implementing the capabilities for what Randy wants to
be able to model and decide on which method is the least
expensive for the specification and EDA tools, and the
most elegant for the model makers and users.
Thanks,
Arpad
============================================================
From: ibis-macro-bounce@xxxxxxxxxxxxx [mailto:ibis-macro-bounce@xxxxxxxxxxxxx]
On Behalf Of Walter Katz
Sent: Tuesday, March 06, 2012 12:15 PM
To: 'Randy Wolff (rrwolff)'; feras@xxxxxxxxxxx; james.zhou@xxxxxxxxxx;
'IBIS-ATM'
Subject: [ibis-macro] Re: Updates to BIRD 145
Randy,
I agree that modeling the on-die and package power distribution is important,
and I also think that IBIS-ATM should be investigating standard ways that IC
Vendors and Package Vendors need to supply power distribution models. I also
know that BIRD 145 does not address the problem that needs to be solved.
The on-die power distribution needs to support a power distribution that
connects multiple Rx and Tx buffers and mechanisms to connect to multiple
package pins. The package model needs to support connecting multiple die power
pins and multiple board power pins.
So I think this problem needs to be addressed in such a ways that it satisfies
the real needs of users by determining the requirements of on-die power
distribution and package power distribution , and how there may be coupling
within the package between power and signal (beyond the affects that rail
voltage have on signal output).
Walter
From: Randy Wolff (rrwolff)
[mailto:rrwolff@xxxxxxxxxx]<mailto:[mailto:rrwolff@xxxxxxxxxx]>
Sent: Tuesday, March 06, 2012 12:56 PM
To: feras@xxxxxxxxxxx<mailto:feras@xxxxxxxxxxx>;
wkatz@xxxxxxxxxx<mailto:wkatz@xxxxxxxxxx>;
james.zhou@xxxxxxxxxx<mailto:james.zhou@xxxxxxxxxx>; 'IBIS-ATM'
Subject: RE: [ibis-macro] Re: Updates to BIRD 145
Hi Walter,
I've been working to add Power Integrity modeling capabilities to DDR3 IBIS
models over the last year, investigating model limitations and EDA software
support. One stumbling block I've run into is the inability to model complex
power/ground decoupling circuits within the IBIS file. I've had to use SPICE
circuits external to the IBIS file when simulating SSO in order to match the
IBIS results to the SPICE results. I'm looking for a good way to attach a
SPICE netlist (perhaps IBIS-ISS) to an IBIS 5.0 power-aware [Model], and
BIRD145 appears to provide a straightforward way to do this.
Two presentations given at recent Summits relate to this particular modeling
challenge:
http://www.eda.org/ibis/summits/feb12/wolff.pdf
http://www.eda.org/ibis/summits/nov11a/wang.pdf
Regards,
Randy
From: ibis-macro-bounce@xxxxxxxxxxxxx<mailto:ibis-macro-bounce@xxxxxxxxxxxxx>
[mailto:ibis-macro-bounce@xxxxxxxxxxxxx]<mailto:[mailto:ibis-macro-bounce@xxxxxxxxxxxxx]>
On Behalf Of Feras Al-Hawari
Sent: Tuesday, March 06, 2012 7:39 AM
To: wkatz@xxxxxxxxxx<mailto:wkatz@xxxxxxxxxx>;
james.zhou@xxxxxxxxxx<mailto:james.zhou@xxxxxxxxxx>; 'IBIS-ATM'
Subject: [ibis-macro] Re: Updates to BIRD 145
Walter,
Again you are mixing our simple proposal with other issues or
misunderstandings. Our proposal (direct call of [Model] and cascading [Model]
with [External Circuit]) is a slight enhancement to what is already there in
IBIS i.e., [External Circuit] . We also believe that there is no need for an IC
vendor to proceed with the evaluation of this proposal, as there are many
qualified and experienced people in the ATM committee to do so.
Feras
From: Walter Katz [mailto:wkatz@xxxxxxxxxx]<mailto:[mailto:wkatz@xxxxxxxxxx]>
Sent: Monday, March 05, 2012 11:20 PM
To: james.zhou@xxxxxxxxxx<mailto:james.zhou@xxxxxxxxxx>; Feras Al-Hawari;
'IBIS-ATM'
Subject: RE: [ibis-macro] Re: Updates to BIRD 145
All,
My general comment to BIRD 145 is that it attempts to handle on-die power in a
confusing and awkward way. I would like some imput from IC Vendors on what
problem they are trying to solve, not how one EDA vendor addresses the problem.
So I think any discussion on BIRD 145 should wait until there is at lease one
IC Vendor supporter, and the IC Vendor describes the problem he is trying to
solve.
Walter
From: ibis-macro-bounce@xxxxxxxxxxxxx<mailto:ibis-macro-bounce@xxxxxxxxxxxxx>
[mailto:ibis-macro-bounce@xxxxxxxxxxxxx]<mailto:[mailto:ibis-macro-bounce@xxxxxxxxxxxxx]>
On Behalf Of James Zhou
Sent: Monday, March 05, 2012 8:57 PM
To: Feras Al-Hawari; 'IBIS-ATM'
Subject: [ibis-macro] Re: Updates to BIRD 145
Hi Feras,
in BIRD145, example 1:
[Circuit Call] RDL_Interconnect | Instantiates [External Circuit] named
| "RDL_Interconnect"
| mapping port pad/node
Port_map vcc 18 | Port to implicit pad connection
Port_map gnd 12 | Port to implicit pad connection
What are the rules to map pad/node to pins? In this example, the die pads have
the same name as the pin names. However, in a general cases (such as the one
shown in IBIS 5.0 page 136-138,) the die pads and pins have different names.
This applies to both BIRD 145 and IBIS 5.0.
Also when it involves power ground pins, the mapping from die pads to pins are
almost never 1 to 1 and how does IBIS or BIRD 145 address this issue?
Regards,
James Zhou
QLogic Corp.
From: Feras Al-Hawari
[mailto:feras@xxxxxxxxxxx]<mailto:[mailto:feras@xxxxxxxxxxx]>
Sent: Monday, March 05, 2012 2:44 PM
To: James Zhou; 'IBIS-ATM'
Subject: RE: Updates to BIRD 145
Hello James,
Both cases could be handled in a more accurate manner if the simulator
supports BIRD 98 and the I/O model contains the KSSO tables. Based on that, the
simulator would scale the IV curves according to the reference voltage
variations (deviations).
Best regards,
Feras
From: James Zhou
[mailto:james.zhou@xxxxxxxxxx]<mailto:[mailto:james.zhou@xxxxxxxxxx]>
Sent: Monday, March 05, 2012 5:21 PM
To: Feras Al-Hawari; 'IBIS-ATM'
Subject: RE: Updates to BIRD 145
Hi Feras,
I have a couple of questions about this BIRD.
Using the following IBIS keywords and values as an example:
---------------------------------------------------------------------------------------------------
[Voltage Range] 1.5000V 1.4250V 1.5750V
[Pullup Reference] 1.5000V 1.4250V 1.5750V
[Temperature Range] 50.0 120.0 -40.0
[Pulldown]
| Voltage I(typ) I(min) I(max)
-1.50000000E+0 -16.49945000E-3 -12.54515100E-3 -17.87071600E-3
-1.42500000E+0 -17.26897000E-3 -13.59391400E-3 -18.38734400E-3
......
---------------------------------------------------------------------------------------------------
Suppose the user has selected the typical case for simulation, corresponding to
voltage = 1.5000V, temperature = 50.0.
For case a) in your email: if an external circuit is inserted between the
external power supply and A_puref, the actual voltage of A_puref can deviate
from 1.5V. As a result the typical V-I curve (which was obtained for
A_puref=1.5000V) will no longer apply to this simulation. What is the proposed
approach for this situation?
For case b) in your email: This BIRD proposes no changes to how the power
supplies are connected to the model when the power nodes are floating. However,
I'd like to enter this question here anyway for the record: what happens if a
user connected the A_puref to a voltage other than 1.5000V (such as 1.52385V)
and selected the typical V-I curve ? Further, what if the user composes a
power circuit outside of IBIS and connects it to the A_puref pins in the EDA
tool?
This BIRD presents a format to include power distribution circuits in IBIS. At
the same time it should also clearly articulate how this new structure and data
should be simulated when power supply voltages deviate from those prescribed
values in native IBIS V-I curves.
Thanks,
James Zhou
QLogic Corp.
From: ibis-macro-bounce@xxxxxxxxxxxxx<mailto:ibis-macro-bounce@xxxxxxxxxxxxx>
[mailto:ibis-macro-bounce@xxxxxxxxxxxxx]<mailto:[mailto:ibis-macro-bounce@xxxxxxxxxxxxx]>
On Behalf Of Feras Al-Hawari
Sent: Monday, March 05, 2012 1:48 PM
To: 'IBIS-ATM'
Subject: [ibis-macro] Updates to BIRD 145
I have updated BIRD 145 (will be uploaded soon) to explain whose responsible
for delivering power to the reserved voltage reference nodes in examples 1 & 2
. The new changes are preceded by **. The bulk of the changes are as shown
below:
|* The pre-defined voltage reference ports (i.e., A_pcref, A_puref,
|* A_pdref, A_gcref) of any [Model] that is called in the circuit
|* can be either: a) manually interconnected by the model developer
to the
|* ports of an [External Circuit] by connecting them to the same
node
|** declared by the [Node Declarations] keyword as shown in example
1 below
|** (i.e., in this case the model developer needs to guarantee that
the
|** [External Circuit] contains the appropriate circuitry to deliver
the
|** required power to each of the voltage reference ports), or b)
automatically
|** interconnected "as usual" by the EDA tool to the corresponding
voltage
|** sources when those ports are left floating as shown in example 2
|** below (i.e., in this case the EDA tool should connect the
reserved
|** voltage reference ports to DC voltage sources with voltage values
|** equal to the corresponding reference voltage values in the
[Model]).
Feras
________________________________
This message and any attached documents contain information from QLogic
Corporation or its wholly-owned subsidiaries that may be confidential. If you
are not the intended recipient, you may not read, copy, distribute, or use this
information. If you have received this transmission in error, please notify the
sender immediately by reply e-mail and then delete this message.
________________________________
This message and any attached documents contain information from QLogic
Corporation or its wholly-owned subsidiaries that may be confidential. If you
are not the intended recipient, you may not read, copy, distribute, or use this
information. If you have received this transmission in error, please notify the
sender immediately by reply e-mail and then delete this message.
Other related posts:
