RE: [ng-spice-devel] Re: snapshot/resimulate. was: [ng-spice-devel] ACS with the "free" Borland compiler


To <ng-spice-devel@ieee.ing.uniroma1.it>
From "Jon Engelbert" <jon@beigebag.com>
Date Wed, 4 Apr 2001 14:56:10 -0400
Delivered-To mailing list ng-spice-devel@ieee.ing.uniroma1.it
Importance Normal
In-Reply-To <200104041534.IAA91472@spnet.com >
Mailing-List contact ng-spice-devel-help@ieee.ing.uniroma1.it; run by ezmlm
Reply-To ng-spice-devel@ieee.ing.uniroma1.it

On Microsoft Windows, the Data Access Objects (DAO) libraries make it
possible to store simulation data into a database.  DAO is "free" with
Windows.  This way, all of the data that is generated by the simulator can
be stored to the hard drive and, if the database is set up logically, then
the data can be retrieved into RAM as needed.  I think that this is the
ideal solution to the problem.
Upon starting the simulation, the simulator would need to set up the
database table for the simulation.
The database could include a single table for each simulation.  The first
field would be the index signal (time or frequency or the "step" variable),
and one field for each of the other signals.  The simulator could call a
data output routine as it does now, and then this data output routine would
simply dump the data into the next row of the database table.
Then the back-end data analysis program would retrieve the data that it
needs from the database.
Writing to a database is relatively fast.  And reading from it is even
faster... at least, this is true with DAO.

On Linux and other systems, I don't know of any free database libraries.
But if there were, then I think that this would be the ideal solution.


Jon Engelbert
President, Beige Bag Software
279 E. Liberty, Ann Arbor, MI 48105
jon@beigebag.com

-----Original Message-----
From: Ed Hudson [mailto:elh@spnet.com]
Sent: Wednesday, April 04, 2001 11:35 AM
To: ng-spice-devel@ieee.ing.uniroma1.it
Cc: elh@spnet.com
Subject: [ng-spice-devel] 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: