Re: confusion about c_comp

On Wed, 20 Dec 2000, Ingraham, Andrew wrote:
> Any simulator that uses the V/T data, must be careful enough to use
> it correctly!
>
> Whatever algorithm it uses, it must be able to duplicate the V/T
> data, by simulating the device connected to the same elements
> (R_fixture, etc.). If it doesn't, the simulator's algorithm is
> wrong.

It is actually very difficult to implement it correctly. I am
curious how they all do in this matter.

C_comp is included in the V/T data, but it is not included in the
pullup/pulldown data. This means that to be truly correct, some kind
of add and remove algorithm is needed, so it will be there at the
ends, but not be double counted in the middle of the transition. A
truly correct implementation of c_comp will tend to magnify errors in
the V/T data, making me believe that some kind of semi-correct
implementation may actually be superior in practice.

Even without c_comp, the V/T support is trouble prone. Sometimes it
is necessary to tolerate some error in data matching in the interest
of stability. It is possible to supply multiple V/T tables that have
conflicting data, or data that cannot actually happen with the simple
topology of an IBIS model. (Driver schedule, bus hold, dynamic clamp
are all attempts to help in these cases.) In these cases, often
something needs to be sacrificed. Some simulators try to fit the
best they can, perhaps with some smoothing or other data munging.
All reject waveforms that don't fit their algorithm. Some are mpre
picky than others. Some just take the first one or two, regardless
of what is best. They all keep the details of the algorithm secret.
 
Received on Wed Dec 20 21:40:53 2000