Re: [ng-spice-devel] ACS with the "free" Borland compiler


To ng-spice-devel@ieee.ing.uniroma1.it
From Steve Hamm <Steve.Hamm@motorola.com>
Date Wed, 4 Apr 2001 09:10:39 -0500 (CDT)
Cc elh@spnet.com
Delivered-To mailing list ng-spice-devel@ieee.ing.uniroma1.it
In-Reply-To <200104040024.RAA87859@spnet.com >
Mailing-List contact ng-spice-devel-help@ieee.ing.uniroma1.it; run by ezmlm
References <aldavis@ieee.org><01040316484909.03528@hobbes ><200104040024.RAA87859@spnet.com >
Reply-To ng-spice-devel@ieee.ing.uniroma1.it

---"Ed" == Ed Hudson <elh@spnet.com> writes:

Ed> this may be to far fetched, but, having written many waveform
Ed> viewers, a really, really usefull feature would be to have
Ed> the waveform viewer linked to the simulator in such a fashion
Ed> that the .raw (or .tr0) file could contain restartable snapshots
Ed> of the simulation.  then, when the waveform viewer attempts
Ed> to use data between these restartable snapshots, the linked in
Ed> simulator starts back up and provides the intermediate data,
Ed> via resimulation from the most immediate previous snapshot.

Ed> this allows the .raw file to be much, much smaller for large
Ed> simulations (eg, a 24hr pll simulation may be otherwise unviewable
Ed> if all data is retained), and potentially speeds up viewing of
Ed> long simulation results dramatically.

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
situation, where a relatively small circuit is run for many, many
timepoints, and each timepoint is quickly calculated.

Also, to restart the simulation these snapshots cannot be just node
voltages. To do this properly, the entire solution vector must be
stored, plus all the information needed to restart the differentiation
for elements which generate differential equations: the state vector,
and as many previous timepoint state vectors as are needed by the
differentiation formula. This can be quite a lot of information,
depending on how the simulator organizes these things. 

Ed> of course, to minimize problems with subsequent changes to
Ed> the simulator, or input data, both the simulator, and the
Ed> entire simulation input deck need to be captured, preferably
Ed> in the (monolithic) results file.  call this ~4mby.

Basically, anything affecting the simulation would need to be stored:
the netlist, any parameters/environment setting, all the convergence
settings... Rather a tedious mess.

--Steve
 


Partial thread listing: