[IBIS-Users] Comments on BIRD95

Hello Syed:

You have made a good start on a difficult problem and have
addressed most of the issues I shared with you privately before
submission. I still have some structural concerns, some of
which may include some of those raised by others.

The biggest contribution of the proposal is that it handles
SSN issues by pulling out the power connection terminal switching
currents directly. These currents include effects such as
crow-bar, pre-driver currents, and even physical or
SPICE modeled on-die bypass currents, which cannot be derived
from just the output voltage waveform information.

There are two major ways to fit this information into IBIS.

1. Use multi-lingual methods entirely
2. Use IBIS format entirely.

Unfortunately, IBIS Ver 4.1 structurally prohibits
mixing of these methods as suggested by BIRD95.
Specifically, if the additional [Series Composite Current]
information is part of a [Model], it cannot be hooked up
to power/ground pin contacts via multi-lingual [External
Circuit]/[Circuit Call] constructs. The existing [Pin Mapping]
method should be used, or else the whole model extension
proposal has to be recast into an externally coded [External
Circuit]. This is a structural limitation of IBIS as it
currently stands.

My preference is not to mix in the added elements derived from
ICEM in this proposal (L_VDDQ, R_VDDQ, L_GND, R_GND), but to
make BIRD95 self-contained directly under [Model] and outside
of the multi-lingual framework. This approach still documents
a format for the important current flow information.

This also avoids getting bogged down in (ICEM) definitions and
on-die power distribution issues that are outside of IBIS models.
Such issues are the inclusion or omission of internal core noise
generators for separate internal clock driver circuitry, and
limiting via codification of one network possible ICEM advances
for more complex networks for higher frequency applications.

The other IBIS structural issue is that the [Series Composite Current]
needs to be defined for all single-ended driver Model_types (including
Open_drain, Open_source and ECL). It also needs to be well-defined
for the floating [Pulldown Reference] and [Pullup Reference] voltage
rails (and possible absolute GND when applicable and when only
[Voltage Range] is specified). I think it is reasonable to ignore
the currents in any of the clamp tables if they are connected to
rail references other than the driver voltage rails - as a
practical compromise since the dominate information is still
captured.

To summarize my recommendations:

(1) Focus only on the [Series Composite Current] as just an IBIS
[Model] addition and take out all of the ICEM based elements and
linkage example. The [Pin Mapping] methodology is already
in place to associate groups of internal power nets to the power
and ground pins.

(2) Add more detail regarding how [Series Composite Current] is
defined for all combinations of Model_types and driver reference
voltages. Specifically, [Series Composite Current] needs to be
explicitly defined with respect to [Pullup Reference] and
[Pulldown Reference] (and GND, if needed) terminals of the
the generic IBIS model. (This indirectly forces the issue on
how the currents are defined/measured externally at the [Model]
power terminals and might need elaboration in the Notes on
Derivation Methods section).

Bob

-- 
Bob Ross
Teraspeed Consulting Group LLC     Teraspeed Labs
121 North River Drive              13610 SW Harness Lane
Narragansett, RI 02882             Beaverton, OR 97008
503-750-6481                       503-430-1065
http://www.teraspeed.com           503-246-8048 Direct
bob@teraspeed.com
|------------------------------------------------------------------
|For help or to subscribe/unsubscribe, email majordomo@eda.org
|with just the appropriate command message(s) in the body:
|
|  help
|  subscribe   ibis       <optional e-mail address, if different>
|  subscribe   ibis-users <optional e-mail address, if different>
|  unsubscribe ibis       <optional e-mail address, if different>
|  unsubscribe ibis-users <optional e-mail address, if different>
|
|or email a written request to ibis-request@eda.org.
|
|IBIS reflector archives exist under:
|
|  http://www.eda.org/pub/ibis/email_archive/  Recent
|  http://www.eda.org/pub/ibis/users_archive/  Recent
|  http://www.eda.org/pub/ibis/email/          E-mail since 1993