Re: [IBIS] Comments on BIRD95

Bob,
Happy New year. Thanks for your comments and pls see our responses
in-line - Syed

On Fri, 2004-12-31 at 11:18, Bob Ross wrote:
> 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.
>

Cisco: Not BIRD95 specific and need to be addressed separately
by the forum.

> 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.
>

Cisco: L_VDDQ, R_VDDQ, L_GND and R_GND are *not* ICEM specific. They
have no relation to ICEM. These parasitics are part of the on-die I/O
buffer structures and are included in the IvsT tables. We added
them in the diagram for clarity and no new keywords are introduced
within BIRD95 for these params.

> 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.
>

Cisco: See response below for item#2

> 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.
>

Cisco: BIRD95 only introduces the [Series Composite Current]. There
are no references to ICEM within BIRD95(in terms of a spec). The only
reference shows up in the Example. It helps the user to understand how
the IvsT(for SSN) eventually gets connected to the Core model(ICEM).

> (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).

Cisco: BIRD95 will support all model_types defined in IBIS. For example,
Open_drain will not have the P-ch xtor and as such the I_cb current
will not be present. So certain tables will go away based on the type
of I/O model used. We can add references to how various unique
Model_types should be handled in a Cookbook or the section in the IBIS
spec called 'Notes on Derivation Methods' neither of which are part of
this BIRD.

Thanks again.

-----------------------------------------------------------------
|For help or to subscribe/unsubscribe, email majordomo@eda.org
|with 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 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
Received on Tue Jan 4 17:07:45 2005