[ibis-macro] Re: The power of BIRD 145 and more clarifications!
- From: "Muranyi, Arpad" <Arpad_Muranyi@xxxxxxxxxx>
- To: 'IBIS-ATM' <ibis-macro@xxxxxxxxxxxxx>
- Date: Wed, 7 Mar 2012 21:45:18 +0000
Todd,
You didn't misread my other posting in which I was talking
about Walter's suggestion of adding the B-element to IBIS-ISS
which could help eliminating the need for cascading [Model]
with [External Circuit].
But my recent posting to which you are responding was in
response to your question:
"From a functional standpoint, what does BIRD 145 provide that could not be
accomplished through BIRD 116?"
in which there was no mention of the "B-element" idea in
IBIS-ISS. So my statement was based on the existing content
of these BIRDs, that's all.
Thanks,
Arpad
==============================================================
From: ibis-macro-bounce@xxxxxxxxxxxxx [mailto:ibis-macro-bounce@xxxxxxxxxxxxx]
On Behalf Of Todd Westerhoff
Sent: Wednesday, March 07, 2012 3:13 PM
To: 'IBIS-ATM'
Subject: [ibis-macro] Re: The power of BIRD 145 and more clarifications!
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.
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<mailto: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>
[mailto:ibis-macro-bounce@xxxxxxxxxxxxx]<mailto:[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>
[mailto:ibis-macro-bounce@xxxxxxxxxxxxx]<mailto:[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.
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<mailto: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>
[mailto:ibis-macro-bounce@xxxxxxxxxxxxx]<mailto:[mailto:ibis-macro-bounce@xxxxxxxxxxxxx]>
On Behalf Of Feras Al-Hawari
Sent: Wednesday, March 07, 2012 2:32 PM
To: wkatz@xxxxxxxxxx<mailto:wkatz@xxxxxxxxxx>; 'Randy Wolff (rrwolff)';
james.zhou@xxxxxxxxxx<mailto: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]<mailto:[mailto:wkatz@xxxxxxxxxx]>
Sent: Tuesday, March 06, 2012 1:15 PM
To: 'Randy Wolff (rrwolff)'; Feras Al-Hawari;
james.zhou@xxxxxxxxxx<mailto: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]<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:
