Andy,
I think you have a pretty good handle on what is likely to happen.
I can expand a little ...
Some environments use the Ramp data to make some basic decisions about
how to set up the simulations.
e.g. which driver on a bi-directional net is likely to cause the
greatest amount of crosstalk.
The infinite edge rate in this case could cause unintended results
even before it gets to the simulator.
Ian Dodd
"Ingraham, Andrew" wrote:
>
> > One subtle point here is whether, or not, the [Model] that has this
> > dV/dt_r
> > parameter also has waveform tables. If it does, the [Ramp] parameters
> > should
> > be ignored by the simulator, anyway.
>
> Not all simulators use the [Rising Waveform] and [Falling Waveform] data if
> it's there. That is one reason why IBIS requires the [Ramp] data even if
> the waveforms are also provided.
>
> Even if the simulator does use the waveform tables, is it prohibited from
> looking at the [Ramp] data? Conceivably, its algorithms might use the
> [Ramp] data, either to enhance its accuracy somehow, or as an internal
> "sanity check" that the tables and [Ramp] data are consistent.
>
> Presumably, the 0/0 values mean the person who created the IBIS data sheet,
> didn't finish. There may be valid reasons for doing that; perhaps this is a
> preliminary model and its customers know and understand that. I won't argue
> that it needs to be fixed, but I don't know the circumstances here.
>
> In the interim, personally I would want to avoid 0/0, since it might be
> mathematically problematic, with unpredictable results. If I were you, I'd
> substitute something like 1/1, which I think should be less likely to cause
> an unexpected outcome. Either the simulator doesn't use it, or you should
> see very slow rising edges in your simulations which should stand out and
> tell you that this model is incomplete for those edges. That is better than
> the simulator blowing its brain to bits and scribbling all over your disk or
> something.
>
> Andy
Received on Wed Apr 4 09:21:01 2001
This archive was generated by hypermail 2.1.8 : Fri Jun 03 2011 - 09:53:47 PDT