outitf.c


To "'ng-spice@ieee.ing.uniroma1.it'" <ng-spice@ieee.ing.uniroma1.it>
From "Gillespie, Alan" <Alan.Gillespie@analog.com>
Date Tue, 16 Jan 2001 11:59:07 -0000
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


Hi Folks,

I think I've got outitf.c fixed, i.e. I've removed the PSPICE
formatting stuff, but left in the device currents hack, the
reference variable status stuff, and the buffered output stuff.
The row buffering "should" also get disabled if you choose
ASCII rawfile format. By the way, is there a runtime option
for setting this, or can it only be done at compile time ?

I checked it using gwave, but with only one example, though.
Other people may want to try it out too. I'll try a few more
things as well, but it seems that other people use spice in
a different way from me, so we'll probably get more mileage
when more folks get to try it. I haven't checked the ASCII
format yet, by the way.

So I've attached a file which is the results of running

diff -c outitf.c outitf.c_0 > outitf.dif

where outitf.c is the original version downloaded from the
CVS, and outitf.c_0 is my new version. The -c option is 'cos
the book on Linux Programming I bought says that that is how
to do it if you want to use patch to alter outitf.c to
outitf.c_0

Is that the easiest way for Paolo or Arno put the new version
in the CVS ?

On the "new" format issue, I noticed that there's a 
"Command: version n" string which seems that ideal place to
put a format version number, and/or other information. I
suggest that if n is greater than the current value (I can't
remember what that is), then the next line could be one saying
"Extra Header Lines : n", followed by n lines of additional
information. This could contain whatever we feel like, but
one particular thing which PSPICE has but spice doesn't is
the temperature value at which the simulation was run. It
may also be useful to keep a copy of all the tolerance values
for the run, and possibly even the settings of other options
during the run. Possibly the statistics dumped at the end of
the output file might be useful. Finally there could be a "Data
Format : xxxxxxxxxxxx" line which, initially could say either
"single" or "double" for the width of the numbers stored.
(Note that this could also apply to ASCII files, allowing
narrower fields for the numbers). Ultimately, if we do the
"batching" of data rows which I suggested in a previous email,
then this line could also contain a field which specified the
block size value, e.g. "Data Format : single blocksize=64".

There is a CSDF (common simulation data format) specification
somewhere, so maybe it's worth seeing if that might be worth
using. That would probably need new reading routines for all
programs like gwave, though.

Any opinions ?

Cheers,

Alan

outitf.dif


Partial thread listing: