RE: [IBIS] Question regarding V-t tables

Bob,

I understand your point. It is usually better to think
positively than negatively. However, some times it is
necessary to establish rules to limit the possibilities
of mistakes. Think about the stop sign situation. It
is a very negative thing!!! You cannot speed through
the intersection at your convenience. You MUST stop.
But how many lives did it save? Probably a lot...

So the question I am asking is twofold:

1) Should we leave the IBIS spec as it is and leave
the potential open for making (bad) models with repeated
Rfixture/Vfixture parameters, or should this be declared
illegal with a statement in the spec, so that such models
could be flagged by the parser before they are released?

I know, tools may have their own protection mechanisms
to guard themselves against situations like this, but at
that point it is too late, the model may be bad, or may
have intentions for which the tool doesn't have the
proper algorithms. It may be better to prevent this
from happening at the earliest stage, when the model is
being made.

2) If we decide to leave the spec as it is and allow
this, should we add new subparameters to the waveform
keywords to specify how this kind of data is intended
to be used by the simulator? For example, use Waveform_1
when the data pattern is 10101010, use Waveform_2 when
the data pattern is 11001100, use Waveform_3 when it is
111000111000, etc...

Arpad
=======================================================

-----Original Message-----
From: Bob Ross [mailto:bob@teraspeed.com]
Sent: Thursday, September 09, 2004 1:10 AM
To: Muranyi, Arpad
Cc: ibis@eda.org
Subject: Re: [IBIS] Question regarding V-t tables

Arpad:

The brief response is that the standard recommendations
such as setting V_fixture to ground and Vcc give excellent
modeling data and USUALLY avoid computational pit falls
for real buffers.

However, different EDA vendors may have different algorithms
with different levels of protection around their algorithms.
So it is difficult to generalize that some setups are not
solvable.

Consider for example, the algorithm on pages 6 and 7 of:

   http://www.eda.org/pub/ibis/summits/jun03a/muranyi1.pdf

Some R_fixture/V_fixture/(V-T) combinatons will most
likely be singular at some time t during the transition
when the denominator passes through 0. Your suggestion
of two different V-T tables for the same R_fixture/V_fixture
is an extreme case where the starting and ending points
and perhaps other time points where voltages are equal would
produce a singular (unsolvable) situation - if both sets of
data are to be used in this algorithm. (I am assuming your
distinct V-T tables satisfy the end-point conditions
consistent with the I-V tables and fixture loads, and
therefore have equal voltages and load currents. You
cannot get a solution for two k(t) table values from
two identical equations.) Different vendors may deal
differently with this type of stiuation.

So the response is to make positive recommendations, which
produce accurate models that simulate well in most tools
- rather than try to come up combination situations that
are likely to fail in some EDA tools.

Bob

-----------------------------------------------------------------
|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 Thu Sep 9 09:44:14 2004