
Notes on the format of "post" files generated by HSPICE.

All copyrights disclaimed on this text file only - 
	this file, hspice-output.txt, is in the public domain.

-----------------------------------------------------------------------------

Sample header from an hspice file, line numbers added for illustration.

 1   00010002000000009601
 2                   09/10/9813:30:19 Copyright (C) 1985-1997 by Avant! Corporation.
 3                              0
 4                             1       1       1     TIME            v(a
 5   v(b             $&%#      1       1       1     TIME            v(a
 6   0.00000E+000.00000E+00 .00000E+00 .12500E-09 .00000E+00 .00000E+00 .2500


Line 1 contains three fixed-width fields of interest:
 0-3	integer (0001 above) the number of automaticly-recorded
	variables in the file. It will be 1 if ".option probe" is specfied,
	larger otherwise.  I call this nauto in my code.

 4-7	integer (0002 above) the number of output variables added by the user's
	.graph, .probe and .plot statements.  I call this nprobe. 

16-19	The version of the fileformat.   Values seen are 9007 and 9601,
	corresponding to the version of HSPICE where the fileformat
	was last changed.

hspice file format "9601" is the default in hspice 98.2 (9007 was
previous).  Difference is in how nodenames 16 characters and longer
are handled.  Processing the fields starting on line 4 as whitespace-seperated
fields filereader always does 9601 correctly, and does 9007 correctly if
nodnames are 15 characters or shorter.

Line 2 seems to be just the silly copyright notice.

Line 3 contains one integer.  If it is 0, there is a single table of
data in the file, and no sweeps are present.  If it is greater than 0,
it indicates how many tables of data are present in the file.
Processing for values 0 and 1 is otherwise done identicaly.
Processing for values greater than one will get interesting.

Starting on line 4 is a set of lines containing the types and names of each
variable.   As noted above, it almost works in all cases to paste
the lines together and treat the result as having whitespace-seperated fields.

First comes an integer for each variable, indicating the variable type.

The first variable is the independent variable.  The integral types for this
also indicates the analysis type.
1	Transient analysis; type is time.
2	AC analysis; type is frequency
3	DC sweep; type is voltage

The type numbers for the dependent variables are:

1	voltage as dependent var in sweep or transient
2	voltage as dependent var in AC analysis
8	current
9	magnitude of current (not verified)
10	real part of current (not verified)
11	imaginary part of current (not verified)
15	current


After the variable-type integers come the variable names.
A variable name of "$&%#" indicates the end of the list; anything after
this on the last line should be ignored.

Next comes the ascii floating-point data.  There are a fixed number of floats
per line, and the data can be thought of as a set of columns.  Sometimes there
is a space between columns, and somtimes there a leading zero for the number
in the next column takes its place, so for "portability" parse as 11-character
fixed fields.

For DC and transient analysis, the number of columns is equal to the number
of variables.
For AC analysis, it appears that the automaticly-inserted dependent variables
have two columns of data that go with them, presumably for the real and
imaginary parts.

In the ascii tables, it appears that if there is a very large value for an
independent-variable (usually 0.1e+31) that indicates the end of a table.


-----------------------------------------------------------------------------

About Binary Hspice files:
generate with ".options POST=1"

Theese files appear to have 16-byte binary header, then an ascii
header similar (identical?) to that from an ascii hspice file,
followed by binary data.

output from test.hsp:
ascii has 292 floating-point values - 97 rows of three, plus one extra.
binary has 1192 bytes in the binary data section - could be 149 doubles or
298 floats, or maybe some is some sort of header/trailer/control info.

binary header is:
00 00 00 04 00 00 00 2b  00 00 00 04 00 00 01 58   .......+.......X

guess: 4 32-bit ints,
fourth one is length in bytes of the ascii header portion.  In this case,
binary data starts at offset 0x0168.

confirmed this by adding another output item to test1.hsp - start of
binary data moves to offset 0x0180, 4th integer in header is 0x170.
With four plotted items, the pattern in the binary data is real
obvious.

Looks like there are 5 more 32-bit longwords, then binary floats.

test1.tr0.binary:
000170  20 20 20 20 20 20 20 20  24 26 25 23 20 20 20 20           $&%#    
000180  00 00 01 70 00 00 00 04  00 00 01 85 00 00 00 04   ...p............
000190  00 00 06 14 00 00 00 00  00 00 00 00 00 00 00 00   ................
0001a0  80 00 00 00 2f 09 70 5f  00 00 00 00 00 00 00 00   ..../.p_........
0001b0  80 00 00 00 2f 89 70 5f  00 00 00 00 00 00 00 00   ..../.p_........

floating-point data appears to start at offset 0x194 here.  It could be
that the value 0x195 (word at 0x188) is related to this offset.  the
value 0x614 at offset 0x190 appears related to the size of the
floating-point data.  At the end of the file we have:

000780  af c5 1b fa 34 54 d0 cd  00 00 00 00 00 00 00 00   ....4T..........
000790  af 6c 87 f9 34 56 bf 95  00 00 00 00 00 00 00 00   .l..4V..........
0007a0  af 24 5e 7d 71 49 f2 ca  00 00 06 14               .$^}qI......

Data block size is 0x7a8-0x194, or 0x614.
Last word is 0x614 - matches word at 0x190.  
Clearly this is a repeat of the block-size.

The pattern for this block structure used for both the ascii header and
the floating point data appears to be: 
	4-word header, last word indicating data size in bytes
	data
	1-word trailer consisting of the size-word.


remaining questions:

What are the 32-bit floating-point values?
single-precision IEEE? single-precision native floating point?  On HP,
these are the same thing so we really can't tell.  I haven't got 
access to hspice binaries for other architectures.

What happens to the binary integers in non big-endian architectures?
Are the files in network-order (i.e. always big-endian and portable)
Or are they in native byte-order?  Idealy, readers should be able to read
any file on any architecture.  
If the files aren't always big-endian, how would one determine the endianness
of the file?

-----------------------------------------------------------------------------


Hspice ascii files containing multiple DC sweeps.

Here is an hspice file produced by a current vs. voltage sweep, with no extra
sweep parameters from ".DC vtest 0 0.6 0.01 vsup 1.6 1.6 0.1"

00010001000000009007    * dospice hspice deck from jpfet.cmd+jpfet.gfa+_loadsfil
e_       10/18/9918:16:59 Copyright (C) 1985-1997 by Avant! Corporation. 
                           0 
                          3      15     VOLTS           i1(rtest        $&%# 
 .00000E+00 .40592E-15 .10000E-01 .23246E-04 .20000E-01 .46289E-04 .30000E-01
 .69128E-04 .40000E-01 .91763E-04 .50000E-01 .11420E-03 .60000E-01 .13642E-03
 .70000E-01 .15845E-03 .80000E-01 .18027E-03 .90000E-01 .20189E-03 .10000E+00
 .22330E-03 .11000E+00 .24451E-03 .12000E+00 .26551E-03 .13000E+00 .28632E-03
 .14000E+00 .30692E-03 .15000E+00 .32731E-03 .16000E+00 .34750E-03 .17000E+00
 .36749E-03 .18000E+00 .38727E-03 .19000E+00 .40685E-03 .20000E+00 .42623E-03
 .21000E+00 .44540E-03 .22000E+00 .46437E-03 .23000E+00 .48313E-03 .24000E+00
 .50170E-03 .25000E+00 .52005E-03 .26000E+00 .53821E-03 .27000E+00 .55616E-03
 .28000E+00 .57390E-03 .29000E+00 .59145E-03 .30000E+00 .60878E-03 .31000E+00
 .62592E-03 .32000E+00 .64285E-03 .33000E+00 .65958E-03 .34000E+00 .67610E-03
 .35000E+00 .69242E-03 .36000E+00 .70854E-03 .37000E+00 .72445E-03 .38000E+00
 .74016E-03 .39000E+00 .75566E-03 .40000E+00 .77096E-03 .41000E+00 .78606E-03
 .42000E+00 .80096E-03 .43000E+00 .81565E-03 .44000E+00 .83013E-03 .45000E+00
 .84442E-03 .46000E+00 .85849E-03 .47000E+00 .87237E-03 .48000E+00 .88604E-03
 .49000E+00 .89951E-03 .50000E+00 .91278E-03 .51000E+00 .92584E-03 .52000E+00
 .93870E-03 .53000E+00 .95135E-03 .54000E+00 .96381E-03 .55000E+00 .97606E-03
 .56000E+00 .98810E-03 .57000E+00 .99995E-03 .58000E+00 .10116E-02 .59000E+00
 .10230E-02 .60000E+00 .10343E-02 .10000E+31


And here is a similar file, with one extra sweep parameter that takes
on only one value; produced by 

".DC vtest 0 0.6 0.01 vsup 1.6 1.6 0.1"

00010001000100009007    * dospice hspice deck from jpfet.cmd+jpfet.gfa+_loadsfil
e_      10/18/9918:18:10 Copyright (C) 1985-1997 by Avant! Corporation. 
                           1                                                    
                          3      15     VOLTS           i1(rtest        0:vsup  
        $&%#              3      15     VOLTS           i1(rtest        0:vsup  
 .16000E+01 .00000E+00 .40592E-15 .10000E-01 .23246E-04 .20000E-01 .46289E-04
 .30000E-01 .69128E-04 .40000E-01 .91763E-04 .50000E-01 .11420E-03 .60000E-01
 .13642E-03 .70000E-01 .15845E-03 .80000E-01 .18027E-03 .90000E-01 .20189E-03
 .10000E+00 .22330E-03 .11000E+00 .24451E-03 .12000E+00 .26551E-03 .13000E+00
 .28632E-03 .14000E+00 .30692E-03 .15000E+00 .32731E-03 .16000E+00 .34750E-03
 .17000E+00 .36749E-03 .18000E+00 .38727E-03 .19000E+00 .40685E-03 .20000E+00
 .42623E-03 .21000E+00 .44540E-03 .22000E+00 .46437E-03 .23000E+00 .48313E-03
 .24000E+00 .50170E-03 .25000E+00 .52005E-03 .26000E+00 .53821E-03 .27000E+00
 .55616E-03 .28000E+00 .57390E-03 .29000E+00 .59145E-03 .30000E+00 .60878E-03
 .31000E+00 .62592E-03 .32000E+00 .64285E-03 .33000E+00 .65958E-03 .34000E+00
 .67610E-03 .35000E+00 .69242E-03 .36000E+00 .70854E-03 .37000E+00 .72445E-03
 .38000E+00 .74016E-03 .39000E+00 .75566E-03 .40000E+00 .77096E-03 .41000E+00
 .78606E-03 .42000E+00 .80096E-03 .43000E+00 .81565E-03 .44000E+00 .83013E-03
 .45000E+00 .84442E-03 .46000E+00 .85849E-03 .47000E+00 .87237E-03 .48000E+00
 .88604E-03 .49000E+00 .89951E-03 .50000E+00 .91278E-03 .51000E+00 .92584E-03
 .52000E+00 .93870E-03 .53000E+00 .95135E-03 .54000E+00 .96381E-03 .55000E+00
 .97606E-03 .56000E+00 .98810E-03 .57000E+00 .99995E-03 .58000E+00 .10116E-02
 .59000E+00 .10230E-02 .60000E+00 .10343E-02 .10000E+31


Note that the data in the second file is identical to that in the
first, except for an extra value "1.6" at the start of the data block.

There is also an additional nonzero field in the first header line.
Hypothesis: this tells us how many sweep-parameter variables are stuck in
the start of the data block.

-----------------------------------------------------------------------------




I recieved this email from a gwave contributor.  I believe that most
of these details have been incorporated into the text above, and have
been verified in the implementation.

From hlee@gltusa.com Fri Mar  5 17:10:24 1999
Date: Fri, 29 Jan 1999 17:41:08 -0800
From: "H. Lee" <hlee@gltusa.com>
To: tell@cs.unc.edu
Cc: hlee@gltusa.com
Subject: Some information about hspice output format

    [The following text is in the "big5" character set]
    [Your display is set for the "iso-8859-1" character set]
    [Some characters may be displayed incorrectly]

I read the hspice.txt file in your gwave distribution
and I would like to add a few point. Hopefully this
will help. As I did not dig into the code to see what
actually get implemented, if you find this something
you already know, just discard this email.

The information I have is derived from Hspice 97.04 so
it is still 9007. I only ran the test for post=2(ascii o/p).

Looks likes that the ascii header did have some
information in there.

eg.
line 1:00050004000000009007    a simple ac run
line 2:                99/01/2819:30:35 Copyright (C) 1985-1997 by
Avanti!,Inc.
line 3:                           0
line 4:                          1       1       1       1
8        2     2
line 5: 8     8     HERTZ       0       1         2
line 6:I(v1         v(1         v(2     i(r2      i(c1
line 7:$&%#         v(1         v(2     i(r2      i(c1

The first number in line 1 "0005" means that in the hspice file
.option line, only post is specified and probes is not specified
in the .option line. The 5 means that including the independent
variable, there are 5 variables that hspice will automatically
store data in the output file.

Further, the first number in line 4 "1" has some meaning too.
It seems that 1 means transient so the independent variable is TIME.
2 means ac analysis so the independent variable is HERZ.
3 means dc analysis so the independent variable is VOLTS.
The three 1's and one 8's following the first 1's in line 4 basically
said there are 1 0's,2 voltages and one current. It also seems that in
the five variables hspice automatically stored for us, for transient
and dc, there are one column of data per variable, for ac, there are
2 column per variable (except '0').

The second number in line 1 "0004" basic said that in hspice file
there are .print or .plot or .probe line for four additional
variables, for example .probe v(1) v(2) i(r2) i(c1). And for these
probed variables, they are magnitude only, thus one column of data
per variable. That come down to 13 columns of data in quickAC.ac0(
HERTZ -> 2 columns, 0 -> one columns, 1 2 I(v1 -> 2 columns each,
v(1 v(2 i(r2 i(c1 -> one column each. The corresponding numbers in
line 4 and line 5 for v(1 v(2 i(r2 i(c1 have meaning, too. For example,
8 means current(.probe i(c1), 9 means magnitude of current(.probe
im(c1)),
10 means real part of current(.probe ir(c1)), 11 means image part of
current
(.probe ii(c1)), etc.

If in hspice file, both post and probes are specified in .option line,
then the first number of line 1 will just be "0001" with the second
number in line 1 specify the actual number of variables probed in
hspice file.  So the number of column of data will be the sum of first
number and second number in line 1.

One last point, if there are sweep in the hspice file. The number in
line 3 will change too. For example, if there is, say .dc vd 0 3.6 0.6
vg 0.9 3.6 0.9, then the number in line 3 will becom 4 for vg = 0.9
1.8 2.7 3.6 and there will be four set of data.

Again, hope this helps and hope that these get implemented in the next
release
of gwave.

Regards,

Hung-Yi Lee

(408)4929068 x182              hlee@gltusa.com



