Re: snapshot/resimulate. was: [ng-spice-devel] ACS with the "free" Borland compiler
Mr. Steve Hamm writes:
> This would not speed up viewing in general. Simulations of very large
> circuits may take minutes per timepoint -- storing the data would be
> much more efficent. PLL simulations can be sort of the opposite
>
i don't think this invalidates my arguments. and i agree,
this doesn't speed up viewing in general. but it may make
viewing tractable.
in my experience as a chip designer, simulators are used both
as initial design creation tools, and later, as verification tools.
these two modes place sufficiently distinct demands on the simulation
system that many simulators don't perform well in both modes.
the threshold for which snapshot/resimulation is usefull is
not a direct function of the size of the circuit, but is a function of
the length of the simulation run vs the time to compute a time point
(large circuits may have many nodes with little activity - a ram,
for example, might have 100 active nodes and a million stable
nodes...,
and, i think that the speed of 'spice' is a function of ckt activity,
after initial convergence).
it may take minutes to resimulate enough subsequent to a stored
snapshot of interest - but if the simulator has to save the entire
simulation data set otherwise, the dataset size for a comparatively
long simulation, the dataset may exceed available disk storage
(70gigabyte disks are ultimately finite).
if i'm interested in the results from iteration 1million to 1million
and 10,
it does me no good if i can't store enough data to get out to
timepoint 1million.
in my experience designing pll's, and other complex analog circuits
with calibration state (eg, self calibrating a/d and d/a converters),
this store/resimulate paradigm would be exceptionally usefull. and
yes,
not all the time - ie, i wouldn't want the simulator wasting such
space for small, early design simulations.
thx.
-elh
Partial thread listing:
- Re: snapshot/resimulate. was: [ng-spice-devel] ACS with the "free" Borland compiler, (continued)