[ibis-macro] Re: The power of BIRD 145 and more clarifications!

  • From: Todd Westerhoff <twesterh@xxxxxxxxxx>
  • To: Arpad Muranyi <Arpad_Muranyi@xxxxxxxxxx>
  • Date: Wed, 07 Mar 2012 23:59:35 -0500 (EST)

Thanks, Arpad.

You're right - I was talking about BIRD 116 with the addition of a B element (BIRD 116B?  Hah!), but should have been explicit in that regard.

Todd.


From: "Arpad Muranyi" <Arpad_Muranyi@xxxxxxxxxx>
To: "IBIS-ATM" <ibis-macro@xxxxxxxxxxxxx>
Sent: Wednesday, March 7, 2012 4:45:18 PM
Subject: [ibis-macro] Re: The power of BIRD 145 and more clarifications!

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.

 

Description: cid:EAFF2D52-4B63-4A05-9D24-B96BE375B7E0@eau.wi.charter.com

Todd Westerhoff

VP, Software Products

 

Signal Integrity Software Inc. • 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 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

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.


Attachment: image001.gif
Description: image001.gif

Attachment: image001.gif
Description: image001.gif

Attachment: image001.gif
Description: image001.gif

Other related posts: