Re: [ng-spice-devel] Re: snapshot/resimulate


To ng-spice-devel@ieee.ing.uniroma1.it
From Ed Hudson <elh@spnet.com>
Date Thu, 12 Apr 2001 10:42:10 -0700
cc elh@spnet.com
Delivered-To mailing list ng-spice-devel@ieee.ing.uniroma1.it
In-Reply-To Message from "Jon Engelbert" <jon@beigebag.com> of "Thu, 12 Apr 2001 13:06:17 EDT." <NDBBJKNCILBBMJOEMBICKENNECAA.jon@beigebag.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 Wed, 04 Apr 2001, Jon Engelbert wrote:
> On Microsoft Windows, the Data Access Objects (DAO) libraries make
> it possible to store simulation data into a database.  DAO is

just to add fire to the flames...

        simulation output data can be considered highly
        structured, and custom access routines can provide
        very significant speed/space advantages over a generic
        database (analgous to the current situation).
        and, if the data is large (multigigabyte), storage
        overhead can be a big limiting factor (the speed argument
        is a reiteration of Mr. Davis's comments).

        however, post simulation, and post analysis (eg, results
        of .measures, etc), can benefit significantly from
        access to some kind of database.

        it is frequently advantageous to be able to exercise circuits
        with a variety of stimulus and conditions, and to be able
        to draw trends of key aspects of analysis results (eg,
        vco freq vs temp, voltage, etc.

        spice2/3 attempt to incorporate some aspect of this large
        scale stimulus/parameter variation (eg, sweeps, .alter), but this
        is actually better left to a higher level driver program,
        that can keep the results of the analysis stored away in
        some sort of database routine, keyed under the simulation
        conditions.

        a link to gnuplot, mathlab, etc, of these 'second-order'
        results is very valuable.

        there are several examples of peoples attempts to drive
        spice from tcl or perl (the non-berkeley (john maneatis?)
        jspice at stanford), or even directly incorporate a perl
        interface (eg, antrim), to atain this higher level control
        of conditions/analysis.

        lastly, suggesting incorporation of any microsoft code
        in an open-source endeavor is quite ironic...

        as a chip designer, i would say that 90-100% of chip design
        is unix hosted, not windows hosted.  test circuits in
        educational settings are one thing, tying spice deep into
        large scale cad flows requires an operating system with
        more capable fundamentals, eg, unix (cygwin not withstanding).
        (i've been in many companies that have an nt-network for
        email/corporate-is, and an array of sparc servers and linux
        boxes on engineer's desks for hosting the cad tools).

                -elh



Partial thread listing: