
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.


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

It appears that a data size word of 0x00000000 may indicate that the block
extends to the end of the file.

Note that the ascii header can be split across multiple binary blocks!
When this is the case, the binary blocks are less than 8K bytes each,
and signal names are not split between blocks.

What do the other words in the header mean?  Here are the headers for
such a "wide" file:

000000  00 00 00 04 00 00 03 fe  00 00 00 04 00 00 1f f0   ................

001ff0  76 28 6c 61 38 37 5f 30  20 20 20 20 20 20 20 20   v(la87_0        
002000  00 00 1f f0 00 00 00 04  00 00 03 fe 00 00 00 04   ................
002010  00 00 1f f0 76 28 6c 61  38 38 5f 30 20 20 20 20   ....v(la88_0    

003ff0  20 20 20 20 76 28 6c 61  35 39 38 5f 30 20 20 20       v(la598_0   
004000  20 20 20 20 00 00 1f f0  00 00 00 04 00 00 01 95       ............
004010  00 00 00 04 00 00 0c a8  76 28 6c 61 35 39 39 5f   ........v(la599_
004020  30 20 20 20 20 20 20 20  76 28 6c 61 36 30 30 5f   0       v(la600_

004cb0  20 20 20 20 20 20 20 20  24 26 25 23 20 20 20 20           $&%#    
004cc0  00 00 0c a8 00 00 00 04  00 00 08 00 00 00 00 04   ................
004cd0  00 00 20 00 00 00 00 00  40 53 33 33 00 00 00 00   .. .....@S33....
004ce0  00 00 00 00 40 53 33 32  00 00 00 00 40 53 33 32   ....@S32....@S32

(at end of this file)

1035f10  00 00 00 00 40 53 33 32  00 00 00 00 40 53 33 32   ....@S32....@S32
1035f20  00 00 00 00 40 53 33 32  00 00 00 00 40 53 33 32   ....@S32....@S32
1035f30  00 00 00 00 40 53 33 32  00 00 00 00 00 00 00 00   ....@S32........
1035f40  71 49 f2 ca 00 00 10 f4                            qI......


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 each data block.   Looks like this holds.

With 2-D sweeps there are multiple "tables," one for each value of the
second (least-frequently-changing) sweep parameter.  The end of a
table is identified by the 1e30 "infinity" value where the next value
of the independent variable be expected.

Here's a complete datafile generated by  ".dc vA 0 1.0 0.1 vsup 10.0 20.0 5"

00010001000100009601    * hspice deck for simple 2-d sweep.                     
        08/07/2000      19:18:19 Copyright (C) 1985-1999 by Avant! Corporation. 
                           3                                                    
                          3      15     VOLTS           i1(r1           0:vsup  
        $&%#              3      15     VOLTS           i1(r1           0:vsup  
0.10000E+020.00000E+000.00000E+000.10000E+000.10000E-030.20000E+000.20000E-03
0.30000E+000.30000E-030.40000E+000.40000E-030.50000E+000.50000E-030.60000E+00
0.60000E-030.70000E+000.70000E-030.80000E+000.80000E-030.90000E+000.90000E-03
0.10000E+010.10000E-020.10000E+31
0.15000E+020.00000E+000.00000E+000.10000E+000.10000E-030.20000E+000.20000E-03
0.30000E+000.30000E-030.40000E+000.40000E-030.50000E+000.50000E-030.60000E+00
0.60000E-030.70000E+000.70000E-030.80000E+000.80000E-030.90000E+000.90000E-03
0.10000E+010.10000E-020.10000E+31
0.20000E+020.00000E+000.00000E+000.10000E+000.10000E-030.20000E+000.20000E-03
0.30000E+000.30000E-030.40000E+000.40000E-030.50000E+000.50000E-030.60000E+00
0.60000E-030.70000E+000.70000E-030.80000E+000.80000E-030.90000E+000.90000E-03
0.10000E+010.10000E-020.10000E+31

Note that the single number on the third line of the file has become a
"3", indicating three sweeps.

Binary files from DC-sweep:

After stripping off the block structure, I believe they are the same.
It appears that each "table" starts a new binary block.  Old versions
of the code used to count on this.  It is looking like we shouldn't do that.



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




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



