[ibis-macro] Re: The power of BIRD 145 and more clarifications!
- From: "Todd Westerhoff" <twesterh@xxxxxxxxxx>
- To: "'IBIS-ATM'" <ibis-macro@xxxxxxxxxxxxx>
- Date: Wed, 07 Mar 2012 16:13:13 -0500 (EST)
Arpad,
Did I misread one of your earlier comments?
I thought you mentioned instantiating the B element inside an IBIS-ISS
subcircuit using BIRD 116. If that was the case, then you could use the
IBIS-ISS syntax to describe RDL or a termination network that isn't
readily handled by the B element itself. And . you could do all that
inside a single subcircuit with a single set of external connections,
instead of trying to coordinate power modeling across a B element and an
associated [External Circuit] as proposed in BIRD 145.
That seems simpler and more straightforward to me. What am I missing?
Thanks,
Todd.
Description: cid:EAFF2D52-4B63-4A05-9D24-B96BE375B7E0@eau.wi.charter.com
Todd Westerhoff
VP, Software Products
Signal Integrity Software Inc. . <http://www.sisoft.com/> www.sisoft.com
6 Clock Tower Place . Suite 250 . Maynard, MA 01754
(978) 461-0449 x24 . <mailto:twesterh@xxxxxxxxxx> twesterh@xxxxxxxxxx
"Three in the morning and I'm still awake,
So I picked up a pen and a page . "
-Sidewalk Prophets
From: ibis-macro-bounce@xxxxxxxxxxxxx
[mailto:ibis-macro-bounce@xxxxxxxxxxxxx] On Behalf Of Muranyi, Arpad
Sent: Wednesday, March 07, 2012 3:16 PM
To: 'IBIS-ATM'
Subject: [ibis-macro] Re: The power of BIRD 145 and more clarifications!
Todd,
BIRD 145 and 116 are different animals.
BIRD 145 is talking about cascading [Model] with [External Circuit].
BIRD 116 is talking about using IBIS-ISS inside [External ***].
While it might be possible to use the concepts in BIRD 116 to
implement something that would eliminate the need for BIRD 145,
I think the outcome would be somewhat messy. I am not saying
this to defend BIRD 145, I just want to make sure we are not
comparing apples and oranges.
Thanks,
Arpad
===============================================================
From: ibis-macro-bounce@xxxxxxxxxxxxx
[mailto:ibis-macro-bounce@xxxxxxxxxxxxx] On Behalf Of Todd Westerhoff
Sent: Wednesday, March 07, 2012 1:57 PM
To: 'IBIS-ATM'
Subject: [ibis-macro] Re: The power of BIRD 145 and more clarifications!
Feras,
From a functional standpoint, what does BIRD 145 provide that could not be
accomplished through BIRD 116?
Todd.
Description: cid:EAFF2D52-4B63-4A05-9D24-B96BE375B7E0@eau.wi.charter.com
Todd Westerhoff
VP, Software Products
Signal Integrity Software Inc. . www.sisoft.com <http://www.sisoft.com/>
6 Clock Tower Place . Suite 250 . Maynard, MA 01754
(978) 461-0449 x24 . twesterh@xxxxxxxxxx
"Three in the morning and I'm still awake,
So I picked up a pen and a page . "
-Sidewalk Prophets
From: ibis-macro-bounce@xxxxxxxxxxxxx
[mailto:ibis-macro-bounce@xxxxxxxxxxxxx] On Behalf Of Feras Al-Hawari
Sent: Wednesday, March 07, 2012 2:32 PM
To: wkatz@xxxxxxxxxx; 'Randy Wolff (rrwolff)'; james.zhou@xxxxxxxxxx;
'IBIS-ATM'
Subject: [ibis-macro] The power of BIRD 145 and more clarifications!
Walter,
In response to your statement:
"My general comment to BIRD 145 is that it attempts to handle on-die power
in a confusing and awkward way"
1) BIRD 145 builds on top of the IBIS 5.0 constructs, specifically we
borrowed many of the ideas from Figure 4 in page 103 in the IBIS 5.0
specification. Based on your statement above you are kind of saying that
the IBIS 5.0 [External Circuit] syntax is confusing and awkward! The power
connections in page 103 in the IBIS 5.0 spec are the same as I have them
in BIRD 145. Such a circuit is used to deliver power from the board
through the package circuitry to the I/O buffer power terminals (the same
as I have it in my BIRD).
2) Bird 145 proposes to replace [External Circuit]s X and Z with
model calls to AVOID the need to: a) develop SPICE-like wrappers in which
the corresponding typ, min, and max IBIS I/O subcircuits are instantiated,
b) develop an [External Circuit] to point to the wrapper subcircuits, and
c) use the [Circuit Call] keyword to call the [External Circuit] wrap
legacy I/O buffers i.e., IBIS [Model] section.
3) When the power is varying at the legacy IBIS I/O power terminals,
then supporting BIRDs 95 and 98 by the simulator will help a lot to get
more accurate results (note BIRD 145 also supports the option to have the
EDA tool automatically connect the power terminals to DC sources as shown
in example 2 and as done by many tools today).
In summary, the [External Circuit] construct is very powerful (not
confusing and awkward) as it leaves the full freedom to an experienced
model developer to model very complex scenarios in which the SPICE
[External circuit] might model the package power distribution as well as
coupled package parasitics and it also allows the developer to connect
such circuits (and deliver power) to I/O buffers as shown in page 103 in
the IBIS 5.0 spec and in example 1 in BIRD 145.
NOTE all this can be done NOW without the reliance on IBIS-ISS, a
developer may use Berkely-SPICE as a language and then provide subcircuits
in the native syntax of the tool's simulator for straight consumption!
Best regards,
Feras
From: Walter Katz [mailto:wkatz@xxxxxxxxxx]
Sent: Tuesday, March 06, 2012 1:15 PM
To: 'Randy Wolff (rrwolff)'; Feras Al-Hawari; james.zhou@xxxxxxxxxx;
'IBIS-ATM'
Subject: RE: [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]
Sent: Tuesday, March 06, 2012 12:56 PM
To: feras@xxxxxxxxxxx; wkatz@xxxxxxxxxx; 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] On Behalf Of Feras Al-Hawari
Sent: Tuesday, March 06, 2012 7:39 AM
To: wkatz@xxxxxxxxxx; 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]
Sent: Monday, March 05, 2012 11:20 PM
To: 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] 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]
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]
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] 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:
