I/O Streaming


To ng-spice@ieee.ing.uniroma1.it
From "James Swonger" <jwsrh@hotmail.com>
Date Fri, 13 Aug 1999 18:33:47 PDT
Delivered-To mailing list ng-spice@ieee.ing.uniroma1.it
Mailing-List contact ng-spice-help@ieee.ing.uniroma1.it; run by ezmlm
Reply-To ng-spice@ieee.ing.uniroma1.it

I have a request. It relates to the use of the simulator within a
graphical user interface environment.

The simulator I'm familiar with (Cadence cdsSpice, may it rest in
peace) was integrated into the design framework by making its
command input, error/text output and graphical output all run
as pipes. That is, the process was fired off like:

tail -f inputBufferFile | cdsSpice {mumble, mumble*}

So the simulator got whatver falls to the bottom of the
inputBufferFile. This makes for easy integration with menu
based design tools; they juct have to cough out the command
to a file and the simulator grabs it.

The output was handled similarly. The simulator version for
use with the design system dumped several output streams
to output files - one for text/error, a different one for
graphics.

In the design system, the graphics output window spawned by
initialization was really something like a tekwindow, and it
was started as

tail -f graphicsStreamFile | displayProcess

The display process was pretty dumb, and the simulator command
language (which was nice, flexible and powerful) used as an
intermediary (the design system sent script streams to the
inputBufferFile and the simulator plotted, erased, etc.

Anyway, what I'd like to see is the availability of similar
streaming ability. I think the input and maybe text are free,
but it would be nice if the user could specify filesystem
paths for the output text and graphics streams on the command
line. I never did figure out how they managed to redirect the
output to the files, some kind of Secret Fortran Trick.

What would be really nice is if the output plotting commands
could be augmented with ones that presupposed a pipe to
either gnuplot, a tekwindow, or some standard (and free)
X-window display process.

Command lanuguage is something I'd also like to expand upon,
but I'll save that for another time. Suffice to say that for
hard-core design, being able to script execution, parameterize
models and control automatic instantiation of components, and
extract results, the command language is what makes the tool
high-leverage - beyond single-point circuit simulation.



_______________________________________________________________
Get Free Email and Do More On The Web. Visit http://www.msn.com

Partial thread listing: