[ibis-macro] Re: Updates to BIRD 145
- From: "Muranyi, Arpad" <Arpad_Muranyi@xxxxxxxxxx>
- To: 'IBIS-ATM' <ibis-macro@xxxxxxxxxxxxx>
- Date: Wed, 7 Mar 2012 05:40:48 +0000
James,
Thanks for the summary. However, I think you misunderstood
what I said about BIRD 125. It is not correct to say that
"In BIRD 125, signal pins are 1-to-1 mapped using [Pin Numbers] (page 7)".
The [Pin Numbers] keyword can be used to define any arbitrary
mapping between pins and pads. That goes for signal as well
as power/GND pins and pads.
Regarding your summary on BIRD 145, I would like to make a
fine point clear. BIRD 145 does not propose to instantiate
[Model]s from [External Circuit]. This instantiation is done
from a new proposed keyword in BIRD 145 called [Model Call]
which is analogous to the existing keyword [Circuit Call].
So if someone wants to cascade a [Model] with [External
Circuit], they would need to use CIRCUITCALL on the [Pin]
list, and a [Circuit Call] keyword to instantiate the
[External Circuit] and a Model Call] to instantiate the
[Model] behind it.
The question we discussed as an alternate solution was
Walter's suggestion to enhance the IBIS-ISS specification
with a "B-element", which would bring an easy way to bring
in legacy buffer models ([Model]s) to be inside [External
Circuit], and thereby eliminate the need to cascade [Model]
with [External Circuit].
This is the capability that is already available in our
current specification, but only with VHDL-AMS, Verilog-a(MS)
or Berkeley-SPICE as the buffer modeling language in
[External Circuit]. None of these languages are attractive
for I-V and V-t curve based buffer modeling for various
reasons, even though a macro library also exists in which
most IBIS buffer types are implemented using these two *-AMS
languages. The suggestion to make the B-element available in
IBIS-ISS would broaden the existing capability of buffer modeling
under [External Circuit] with the IBIS-ISS language if we adopted
the BIRD 116 proposal to add IBIS-ISS to [External Model] and
[External Circuit]. This is the mechanism that I would refer
to "instantiating" a [Model] from [External Circuit] via the
IBIS-ISS B-element.
Regarding your #3 item "BIRD144 is about using a new "language" (i.e.
Touchstone) in [External Model]",
it is not only for [External Model] but also for [External Circuit].
Regarding your #4 item "Features in 144 or 145 are not in 116. It is also true
vice versa."
This can be a little misleading too. BIRD 144 is a subset of
BIRD 116, because it allows you to do a subset of what can also
be done with BIRD 116. The only difference is that it does it
by eliminating the IBIS-ISS wrapper, kind of like a shorthand
option. BIRD 145 is kind of independent from BIRD 116 and 144,
because it addresses the cascading of [Model] with [External
Circuit] which is an independent topic from using IBIS-ISS,
including Touchstone models inside [External ***].
Sorry for being so nitpicky, but now that we are approaching
decision time, I think these details are important to keep
straight in order to be able to make the right decisions...
Thanks,
Arpad
===================================================================
From: James Zhou [mailto:james.zhou@xxxxxxxxxx]
Sent: Tuesday, March 06, 2012 6:47 PM
To: Muranyi, Arpad; Feras Al-Hawari; 'IBIS-ATM'
Subject: RE: Updates to BIRD 145
Hi Arpad,
Thanks for your clarification. Based on your response and today's
teleconference, the existing issues and proposed solutions are summarized below.
(1) die pad to package pin mapping: Arpad pointed out that this issue should be
addressed by BIRD125, not by BIRD145. In BIRD 125, signal pins are 1-to-1
mapped using [Pin Numbers] (page 7). For power pin/node mapping, my experience
is that most package designs have different numbers of power pins vs. power
pads for the same net. Even though power balls or pads are often lumped into
smaller number of nodes, the number of die-pad nodes are still generally
different from the number of package pin nodes. I think it is quite
straightforward and necessary to allow association of different numbers of
power die-pad nodes to package pin nodes.
(2) one of the main focuses of BIRD145 is to allow the direct instantiation of
legacy IBIS models from external circuits, which can be used for on-die PDN or
signal interconnect models. Arpad has pointed out that IBIS5.0 already had
support for this capability (e.g. example on page 136) and, IBIS 145 merely
enhances that capability. As end-users of IBIS models, my colleagues and myself
believe that the capability to model on-die signal and power interconnects is
a very important and much needed feature in SI and PI simulations. The changes
proposed by BIRD 145 to allow direct instantiation of legacy IBIS models from
external circuits has significant value to the end-user applications. It allows
the upgrade path to use existing IBIS models with added feature of on-die
interconnect and PDNs. Also I believe the outstanding issues in BIRD145 are
secondary and should be straightforward to fix, due to the fact its impact to
the syntax is rather insignificant and, its approach is quite straightforward.
(3) BIRD145 and 144 are largely independent of each other. BIRD144 is about
using a new "language" (i.e. Touchstone) in [External Model], which is a
different subject from BIRD145.
(4) BIRD145 (or 144) is not mutually exclusive with 116. Features in 144 or
145 are not in 116. It is also true vice versa.
Regards,
James Zhou
QLogic Corp.
From: Muranyi, Arpad
[mailto:Arpad_Muranyi@xxxxxxxxxx]<mailto:[mailto:Arpad_Muranyi@xxxxxxxxxx]>
Sent: Tuesday, March 06, 2012 10:58 AM
To: James Zhou; Feras Al-Hawari; 'IBIS-ATM'
Subject: RE: Updates to BIRD 145
James,
I think the mapping rules are pretty well defined in the v5.0
specification and illustrated on pg. 136-138 in the spec.
If you use the name of a [Pin] in Port_map, the assumption
is that this connection is made to a pad on the dies that is
connected to the pin with a 1-to-1 package path. If you
use a declared die node name (which can also serve as an
on-die pad name), you are making a connection to a declared
on-die node or die-pad for [External ***] in the Port_map.
BIRD 145 seems to allow the connection between reserved
power and GND ports to on-die nodes (which is new). This
is shown in example 1, using nodes a1, b1, d1, e1 and
a2, b2, d2, e2. In the past, these power and GND reserved
nodes could only be connected (and grouped) via the
[Pin Mapping] keyword to specific "pins", which were
actually on-die pads with an assumed 1-to-1 mapping
between pins and pads. Example 2 of BIRD 145 shows that
you can still use the old way of connecting these power
ports if you don't spell them out in the Port_map.
However, Figure 12 on pg. 136 included a few things which
are actually not supported in the specification yet. For
example, the association between pad_2a and pad_2b and pin 2
or pad_4 and pins 4a and 4b, but even pad_11 and pin 11
cannot be defined with the current package modeling
capabilities in IBIS. This figure was a forward looking
example using the ideas we were working on with the ICM
specification. Unfortunately we never finished these
concepts.
BIRD 145 does not address these non 1-to-1 package modeling
issues. That should be dealt with in a package BIRD, and
I am actually addressing that in BIRD 125.
I hope this answers your questions.
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 James Zhou
Sent: Monday, March 05, 2012 7: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.
________________________________
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:
