BIRD14 Reply

To John Keifer and IBIS Committee:

Thank you John for your response. I still have a problem with Cref being in
IBIS (as a timing spec validation capacitor), but you may have a valid
argument for having it in. My problem is that IBIS models are used for
signal integrity applications and also for timing applications ON THE NET
under the actual (transmission line like) load conditions. Cref does not
enter into the picture other than perhaps computing some timing calibration
adjustment parameter to correlate timing specified based by data book test
conditions, and waveform shape timing change due to actual load conditions.
So if Cref is really useful then I would not object to having it in. At
this time, however, I do not see Cref or any other proposed parameter as
being required. Any parameter that is not required cannot be relied upon to
exist by simulator vendors. So at worst the additional parameters may be
for information only. I am not familiar with timing data bases, but I
accept as you indicated that they would be based on the data book
specification load conditions. Comments anyone?

My primary concern about [SPECS] is that it is a good idea that needs to
be thought out thoroughly before it is adopted because it would be harmful
to IBIS for compatibilty reasons to be stuck with a poor (or limited)
implementation.

In terms of "indirection", one complication may be to those implementers
who are providing model parameter display capability. Now they may also
have to consider actual [Component] and the actual pin number to correctly
characterize the [Model] (Several components can refer to the same model
in a file). The "indirection" issue can be resolved easily, but we already
have complicaitons with new keywords for [Package Model], [Pin_Mapping],
[Diff_Pin], some of which override parameters. Currently IBIS [Models] can
reside in separate files (but potentially have the same name) and (optional)
package models can reside in other files. This all may imply some
simulator specific indexing techniques to tie all of the variations together,
so appropriate care is needed before adding another variation.

Should the [Specs] include all available sub-parameters? Should it be split
up into two keyword: [Required Specs] and [Optional Specs]? What happens
if a new sub-parameter is added at a later date? Alternatively, should
[Specs] just contain a minimal set of overrides so that it cannot be
overused?, E.g., does C_comp really vary significantly in practice for the I/O
structure with the same set of VI data?

Adding Model_type could be one of the more useful additions. It is possible
with just one filled [Model] (e.g. an I/O model) to use it for all of the
model_types of a buffer including Input and the Open_drain, Open_sink cases.
Tables which are not used can still exist in the [Model]. For example,
IBIS_CHK accepts an Input model with a [Ramp] specificaton. Assuming the
clamping curves are the same, the C_comp for I/O would be larger than C_comp
for the same model as an Input, and [Spec] captures this variation. This
would be an example of a very robust usage of the [Spec] capability.

What about optional sub-parameters of Polarity and Enable? It would be
wasteful to repeat a complete model if just the Polarity has changed.

I am raising these questions to promote discussion and consideration. I
believe that support of the proposed [Spec] keyword would be REQUIRED by
all implementors because the keyword intentionally alters the [Model] for
a specific pin. Therefore, I feel that extra care and consideration be
taken before we adopt this part of BIRD14.

Bob Ross
Interconnectix, Inc.

  
Received on Wed May 11 22:38:16 1994