add specification documents
This commit is contained in:
parent
e88c92bbc1
commit
1d437f498c
337
doc/spec.html
Normal file
337
doc/spec.html
Normal file
@ -0,0 +1,337 @@
|
|||||||
|
<HTML>
|
||||||
|
<HEAD><TITLE>Computer Aids for VLSI Design</TITLE></HEAD>
|
||||||
|
<BODY BGCOLOR="#FFFFFF">
|
||||||
|
<HR BREAK>
|
||||||
|
<CENTER><FONT SIZE=6><B>Computer Aids for VLSI Design</B></FONT></CENTER>
|
||||||
|
<CENTER><FONT SIZE=5><B><I>Steven M. Rubin</I></B></FONT></CENTER>
|
||||||
|
<CENTER><FONT SIZE=4><B>Copyright © 1994</B></FONT></CENTER>
|
||||||
|
<HR>
|
||||||
|
<H1><CENTER>Appendix C: <A NAME="GDSFormat">GDS II Format</A></CENTER></H1>
|
||||||
|
<CENTER><TABLE BORDER=0><TR><TD><A HREF="chapb.html"><IMG SRC="../images/iconbackarrow.gif" ALT="Prev" BORDER=0></A></TD>
|
||||||
|
<TD><B><CENTER><A HREF="../index.html">Appendix 3 of 7</A></CENTER></B></TD>
|
||||||
|
<TD><A HREF="chapd.html"><IMG SRC="../images/iconforearrow.gif" ALT="Next" BORDER=0></A></TD></TR></TABLE></CENTER>
|
||||||
|
<HR>
|
||||||
|
<P>
|
||||||
|
In the design of integrated circuits, the most popular format for
|
||||||
|
interchange is the Calma <B>GDS II</B> stream format (GDS II is a trademark
|
||||||
|
of Calma Company, a wholly owned subsidiary of General Electric Company, U.S.A.).
|
||||||
|
For many years, this format was the only one of its kind and many other
|
||||||
|
vendors accepted it in their systems.
|
||||||
|
Although Calma has updated the format as their CAD systems have developed,
|
||||||
|
they have maintained backward compatibility so that no GDS II files
|
||||||
|
become obsolete.
|
||||||
|
This is important because
|
||||||
|
GDS II is a binary format that makes assumptions about integer and
|
||||||
|
floating-point representations.
|
||||||
|
<P>
|
||||||
|
A GDS II circuit description is a collection of cells that may contain
|
||||||
|
geometry or other cell references.
|
||||||
|
These cells, called <B><A NAME="GDSStructure">structures</A></B> in GDS II parlance, have alphanumeric
|
||||||
|
names up to 32 characters long.
|
||||||
|
A library of these structures is contained in a file that consists of
|
||||||
|
a library header, a sequence of structures, and a library tail.
|
||||||
|
Each structure in the sequence consists of a structure header, a sequence
|
||||||
|
of <B><A NAME="GDSElement">elements</A></B>, and a structure tail.
|
||||||
|
There are seven kinds of elements: <B>boundary</B> defines a filled polygon,
|
||||||
|
<B>path</B> defines a wire, <B>structure reference</B> invokes a subcell,
|
||||||
|
<B>array reference</B> invokes an array of subcells, <B>text</B> is for
|
||||||
|
documentation, <B>node</B> defines an electrical path, and <B>box</B>
|
||||||
|
places rectangular geometry.
|
||||||
|
|
||||||
|
<P><HR><BR><H2>C.1 Record Format</H2><P>
|
||||||
|
|
||||||
|
In order to understand the precise format of the above GDS II components,
|
||||||
|
it is first necessary to describe the general record format.
|
||||||
|
Each GDS II record has a 4-byte header that specifies the record size and
|
||||||
|
function.
|
||||||
|
The first 2 bytes form a 16-bit integer that contains the record length
|
||||||
|
in bytes.
|
||||||
|
This length includes the 4-byte header and must always be an even
|
||||||
|
number.
|
||||||
|
The end of a record can contain a single null byte if the record contents
|
||||||
|
is an odd number of bytes long.
|
||||||
|
The third byte of the header contains the type of the record and the
|
||||||
|
fourth byte contains the type of the data.
|
||||||
|
Since the data type is constant for each record type, this 2-byte field
|
||||||
|
defines the possible records as shown in Figs. C.1 and C.2.
|
||||||
|
<P>
|
||||||
|
<CENTER><TABLE BORDER=2><TR><TD><TABLE>
|
||||||
|
<TR><TD><B>File Header Records:</B></TD><TD><B>Bytes 3 and 4</B> </TD><TD><B>Parameter Type</B></TD></TR>
|
||||||
|
<TR><TD COLSPAN=3><HR></TD></TR>
|
||||||
|
<TR><TD>HEADER</TD><TD><CENTER>0002</CENTER></TD><TD>2-byte integer</TD></TR>
|
||||||
|
<TR><TD>BGNLIB</TD><TD><CENTER>0102</CENTER></TD><TD>12 2-byte integers</TD></TR>
|
||||||
|
<TR><TD>LIBNAME</TD><TD><CENTER>0206</CENTER></TD><TD>ASCII string</TD></TR>
|
||||||
|
<TR><TD>REFLIBS</TD><TD><CENTER>1F06</CENTER></TD><TD>2 45-character ASCII strings</TD></TR>
|
||||||
|
<TR><TD>FONTS</TD><TD><CENTER>2006</CENTER></TD><TD>4 44-character ASCII strings</TD></TR>
|
||||||
|
<TR><TD>ATTRTABLE</TD><TD><CENTER>2306</CENTER></TD><TD>44-character ASCII string</TD></TR>
|
||||||
|
<TR><TD>GENERATIONS</TD><TD><CENTER>2202</CENTER></TD><TD>2-byte integer</TD></TR>
|
||||||
|
<TR><TD>FORMAT</TD><TD><CENTER>3602</CENTER></TD><TD>2-byte integer</TD></TR>
|
||||||
|
<TR><TD>MASK</TD><TD><CENTER>3706</CENTER></TD><TD>ASCII string</TD></TR>
|
||||||
|
<TR><TD>ENDMASKS</TD><TD><CENTER>3800</CENTER></TD><TD>No data</TD></TR>
|
||||||
|
<TR><TD>UNITS</TD><TD><CENTER>0305</CENTER></TD><TD>2 8-byte floats</TD></TR>
|
||||||
|
<TR><TD COLSPAN=3> </TD></TR>
|
||||||
|
<TR><TD><B>File Tail Records:</B></TD><TD><B>Bytes 3 and 4</B></TD><TD><B>Parameter Type</B></TD></TR>
|
||||||
|
<TR><TD COLSPAN=3><HR></TD></TR>
|
||||||
|
<TR><TD>ENDLIB</TD><TD><CENTER>0400</CENTER></TD><TD>No data</TD></TR>
|
||||||
|
<TR><TD COLSPAN=3> </TD></TR>
|
||||||
|
<TR><TD><B>Structure Header Records: </B></TD><TD><B>Bytes 3 and 4</B></TD><TD><B>Parameter Type</B></TD></TR>
|
||||||
|
<TR><TD COLSPAN=3><HR></TD></TR>
|
||||||
|
<TR><TD>BGNSTR</TD><TD><CENTER>0502</CENTER></TD><TD>12 2-byte integers</TD></TR>
|
||||||
|
<TR><TD>STRNAME</TD><TD><CENTER>0606</CENTER></TD><TD>Up to 32-characters ASCII string</TD></TR>
|
||||||
|
<TR><TD COLSPAN=3> </TD></TR>
|
||||||
|
<TR><TD><B>Structure Tail Records:</B></TD><TD><B>Bytes 3 and 4</B></TD><TD><B>Parameter Type</B></TD></TR>
|
||||||
|
<TR><TD COLSPAN=3><HR></TD></TR>
|
||||||
|
<TR><TD>ENDSTR</TD><TD><CENTER>0700</CENTER></TD><TD>No data</TD></TR>
|
||||||
|
</TABLE></TD></TR><TR><TD><B>FIGURE C.1 </B>GDS II header record types.</TD></TR></TABLE></CENTER>
|
||||||
|
<P>
|
||||||
|
Magnetic tapes containing GDS II files will have 2048 byte blocks that
|
||||||
|
contain these records.
|
||||||
|
The block size is standardized but has no bearing on record length or
|
||||||
|
position.
|
||||||
|
There is also a capability for circuits that require multiple
|
||||||
|
reels of tape.
|
||||||
|
<P>
|
||||||
|
<CENTER><TABLE BORDER=2><TR><TD><TABLE>
|
||||||
|
<TR><TD><B>Element Header Records:</B></TD><TD><B>Bytes 3 and 4 </B></TD><TD><B>Parameter Type</B></TD></TR>
|
||||||
|
<TR><TD COLSPAN=3><HR></TD></TR>
|
||||||
|
<TR><TD>BOUNDARY</TD><TD><CENTER>0800</CENTER></TD><TD>No data</TD></TR>
|
||||||
|
<TR><TD>PATH</TD><TD><CENTER>0900</CENTER></TD><TD>No data</TD></TR>
|
||||||
|
<TR><TD>SREF</TD><TD><CENTER>0A00</CENTER></TD><TD>No data</TD></TR>
|
||||||
|
<TR><TD>AREF</TD><TD><CENTER>0B00</CENTER></TD><TD>No data</TD></TR>
|
||||||
|
<TR><TD>TEXT</TD><TD><CENTER>0C00</CENTER></TD><TD>No data</TD></TR>
|
||||||
|
<TR><TD>NODE</TD><TD><CENTER>1500</CENTER></TD><TD>No data</TD></TR>
|
||||||
|
<TR><TD>BOX</TD><TD><CENTER>2D00</CENTER></TD><TD>No data</TD></TR>
|
||||||
|
<TR><TD COLSPAN=3> </TD></TR>
|
||||||
|
<TR><TD><B>Element Contents Records: </B></TD><TD><B>Bytes 3 and 4</B></TD><TD><B>Parameter Type</B></TD></TR>
|
||||||
|
<TR><TD COLSPAN=3><HR></TD></TR>
|
||||||
|
<TR><TD>ELFLAGS</TD><TD><CENTER>2601</CENTER></TD><TD>2-byte integer</TD></TR>
|
||||||
|
<TR><TD>PLEX</TD><TD><CENTER>2F03</CENTER></TD><TD>4-byte integer</TD></TR>
|
||||||
|
<TR><TD>LAYER</TD><TD><CENTER>0D02</CENTER></TD><TD>2-byte integers</TD></TR>
|
||||||
|
<TR><TD>DATATYPE</TD><TD><CENTER>0E02</CENTER></TD><TD>2-byte integer</TD></TR>
|
||||||
|
<TR><TD>XY</TD><TD><CENTER>1003</CENTER></TD><TD>Up to 200 4-byte integer pairs</TD></TR>
|
||||||
|
<TR><TD>PATHTYPE</TD><TD><CENTER>2102</CENTER></TD><TD>2-byte integer</TD></TR>
|
||||||
|
<TR><TD>WIDTH</TD><TD><CENTER>0F03</CENTER></TD><TD>4-byte integer</TD></TR>
|
||||||
|
<TR><TD>SNAME</TD><TD><CENTER>1206</CENTER></TD><TD>Up to 32-character ASCII string</TD></TR>
|
||||||
|
<TR><TD>STRANS</TD><TD><CENTER>1A01</CENTER></TD><TD>2-byte integer</TD></TR>
|
||||||
|
<TR><TD>MAG</TD><TD><CENTER>1B05</CENTER></TD><TD>8-byte float</TD></TR>
|
||||||
|
<TR><TD>ANGLE</TD><TD><CENTER>1C05</CENTER></TD><TD>8-byte float</TD></TR>
|
||||||
|
<TR><TD>COLROW</TD><TD><CENTER>1302</CENTER></TD><TD>2 2-byte integers</TD></TR>
|
||||||
|
<TR><TD>TEXTTYPE</TD><TD><CENTER>1602</CENTER></TD><TD>2-byte integer</TD></TR>
|
||||||
|
<TR><TD>PRESENTATION</TD><TD><CENTER>1701</CENTER></TD><TD>2-byte integer</TD></TR>
|
||||||
|
<TR><TD>ASCII STRING</TD><TD><CENTER>1906</CENTER></TD><TD>Up to 512-character string</TD></TR>
|
||||||
|
<TR><TD>NODETYPE</TD><TD><CENTER>2A02</CENTER></TD><TD>2-byte integer</TD></TR>
|
||||||
|
<TR><TD>BOXTYPE</TD><TD><CENTER>2E02</CENTER></TD><TD>2-byte integer</TD></TR>
|
||||||
|
</TABLE></TD></TR><TR><TD><B>FIGURE C.2 </B>GDS II element record types.</TD></TR></TABLE></CENTER>
|
||||||
|
|
||||||
|
<P><HR><BR><H2>C.2 <A NAME="GDSLibrary">Library</A> Head and Tail</H2><P>
|
||||||
|
|
||||||
|
A GDS II file header always begins with a HEADER record the parameter of which
|
||||||
|
contains the GDS II version number used to write the file.
|
||||||
|
For example, the bytes 0, 6, 0, 2, 0, 1 at the start of the file constitute
|
||||||
|
the header record for a version-1 file.
|
||||||
|
Following the HEADER comes a BGNLIB record that contains the date of the
|
||||||
|
last modification and the date of the last access to the file.
|
||||||
|
Dates take six 2-byte integers to store the year, month, day, hour, minute, and
|
||||||
|
second.
|
||||||
|
The third record of a file is the LIBNAME, which identifies the name of
|
||||||
|
this library file.
|
||||||
|
For example, the bytes 0, 8, 2, 6, "C", "H", "I", "P" define a
|
||||||
|
library named "CHIP."
|
||||||
|
Following the LIBNAME record there may be any of the optional header records:
|
||||||
|
REFLIBS to name up to two reference libraries, FONTS to name up to four
|
||||||
|
character fonts, ATTRTABLE to name an attribute file, GENERATIONS to
|
||||||
|
indicate the number of old file copies to keep, and FORMAT to indicate the
|
||||||
|
nature of this file.
|
||||||
|
The strings in the REFLIBS, FONTS, and ATTRTABLE records must be the
|
||||||
|
specified length, padded with zero bytes.
|
||||||
|
<P>
|
||||||
|
The parameter to FORMAT has the value 0 for an archived file and the
|
||||||
|
value 1 for a filtered file.
|
||||||
|
Filtered files contain only a subset of the mask layers and that subset
|
||||||
|
is described with one or more MASK records followed by an ENDMASK
|
||||||
|
record.
|
||||||
|
The string parameter in a MASK record names layers and sequences of layers;
|
||||||
|
for example, "1 3 5-7."
|
||||||
|
<P>
|
||||||
|
The final record of a file header is the UNITS record and it is not optional.
|
||||||
|
The parameters to this record contain the number of user units per
|
||||||
|
database unit (typically less than 1 to allow granularity of user
|
||||||
|
specification) and the number of meters per database unit (typically much
|
||||||
|
less than 1 for IC specifications).
|
||||||
|
<P>
|
||||||
|
Eight-byte floating-point numbers have a sign at the top of the first
|
||||||
|
byte, a 7-bit exponent in the rest of that byte, and 7 more bytes that
|
||||||
|
compose a mantissa (all to the right of an implied decimal point).
|
||||||
|
The exponent is a factor of 16 in excess-64 notation (that is, the mantissa
|
||||||
|
is multiplied by 16 raised to the true value of the exponent, where the
|
||||||
|
true value is its integer representation minus 64).
|
||||||
|
<P>
|
||||||
|
Following the file header records come the structure records.
|
||||||
|
After the last structure has been defined, the file terminates with
|
||||||
|
a simple ENDLIB record.
|
||||||
|
Note that there is no provision for the specification of a root
|
||||||
|
structure to define a circuit; this must be tracked
|
||||||
|
by the designer.
|
||||||
|
|
||||||
|
<P><HR><BR><H2>C.3 Structure Head and Tail</H2><P>
|
||||||
|
|
||||||
|
Each structure has two header records and one tail record that sandwich
|
||||||
|
an arbitrary list of elements.
|
||||||
|
The first structure header is the BGNSTR record, which contains the creation
|
||||||
|
date and the last modification date.
|
||||||
|
Following that is the STRNAME record, which names the structure using
|
||||||
|
any alphabetic or numeric characters, the dollar sign, or the underscore.
|
||||||
|
The structure is then open and any of the seven elements can be listed.
|
||||||
|
<P>
|
||||||
|
The last record of a structure is the ENDSTR.
|
||||||
|
Following it must be another BGNSTR or the end of the library, ENDLIB.
|
||||||
|
|
||||||
|
<P><HR><BR><H2>C.4 <A NAME="GDSBoundary">Boundary Element</A></H2><P>
|
||||||
|
|
||||||
|
The boundary element defines a filled polygon.
|
||||||
|
It begins with a BOUNDARY record, has an optional ELFLAGS and PLEX record,
|
||||||
|
and then has required LAYER, DATATYPE, and XY records.
|
||||||
|
<P>
|
||||||
|
The ELFLAGS record, which appears optionally in every element, has two
|
||||||
|
flags in its parameter to indicate template data (if bit 16 is set)
|
||||||
|
or external data (if bit 15 is set).
|
||||||
|
This record should be ignored on input and excluded from output.
|
||||||
|
Note that the GDS II integer has bit 1 in the leftmost or most significant
|
||||||
|
position so these two flags are in the least significant bits.
|
||||||
|
<P>
|
||||||
|
The PLEX record is also optional to every element and defines element
|
||||||
|
structuring by aggregating those that have common plex numbers.
|
||||||
|
Although a 4-byte integer is available for plex numbering, the
|
||||||
|
high byte (first byte) is a flag that indicates the head of the plex if its least
|
||||||
|
significant bit (bit 8) is set.
|
||||||
|
<P>
|
||||||
|
The LAYER record is required to define which layer (numbered 0 to 63) is to
|
||||||
|
be used for this boundary.
|
||||||
|
The meaning of these layers is not defined rigorously and must be
|
||||||
|
determined for each design environment and library.
|
||||||
|
<P>
|
||||||
|
The DATATYPE record contains unimportant information and its argument should
|
||||||
|
be zero.
|
||||||
|
<P>
|
||||||
|
The XY record contains anywhere from four to 200 coordinate pairs
|
||||||
|
that define the outline of the polygon.
|
||||||
|
The number of points in this record is defined by the record length.
|
||||||
|
Note that boundaries must be closed explicitly, so the first and last
|
||||||
|
coordinate values must be the same.
|
||||||
|
|
||||||
|
<P><HR><BR><H2>C.5 <A NAME="GDSPath">Path Element</A></H2><P>
|
||||||
|
|
||||||
|
A path is an open figure with a nonzero width that is typically used
|
||||||
|
to place wires.
|
||||||
|
This element is initiated with a PATH record followed by the optional ELFLAGS
|
||||||
|
and PLEX records.
|
||||||
|
The LAYER record must follow to identify the desired path material.
|
||||||
|
Also, a DATATYPE record must appear and an XY record to define the coordinates
|
||||||
|
of the path.
|
||||||
|
From two to 200 points may be given in a path.
|
||||||
|
<P>
|
||||||
|
Prior to the XY record of a path specification there may be two
|
||||||
|
optional records called PATHTYPE and WIDTH.
|
||||||
|
The PATHTYPE record describes the nature of the path segment
|
||||||
|
ends, according to its parameter value.
|
||||||
|
If the value is 0, the segments will have square ends that terminate
|
||||||
|
at the path vertices.
|
||||||
|
The value 1 indicates rounded ends and the value 2 indicates
|
||||||
|
square ends that overlap their vertices by one-half of their width.
|
||||||
|
The width of the path is defined by the optional WIDTH record.
|
||||||
|
If the width value is negative, then it will be independent of any
|
||||||
|
structure scaling (from MAG records, see next section).
|
||||||
|
|
||||||
|
<P><HR><BR><H2>C.6 <A NAME="GDSStructureRef">Structure Reference Element</A></H2><P>
|
||||||
|
|
||||||
|
Hierarchy is achieved by allowing structure references (instances)
|
||||||
|
to appear in other structures.
|
||||||
|
The SREF record indicates a structure reference and is followed
|
||||||
|
by the optional ELFLAGS and PLEX records.
|
||||||
|
The SNAME record then names the desired structure and an XY record
|
||||||
|
contains a single coordinate to place this instance.
|
||||||
|
It is legal to make reference to structures that have not yet been
|
||||||
|
defined with STRNAME.
|
||||||
|
<P>
|
||||||
|
Prior to the XY record there may be optional transformation records.
|
||||||
|
The STRANS record must appear first if structure transformations are desired.
|
||||||
|
Its parameter has bit flags that indicate mirroring in <I>x</I> before rotation
|
||||||
|
(if bit 1 is set), the use of absolute magnification (if bit 14 is set),
|
||||||
|
and the use of absolute rotation (if bit 15 is set).
|
||||||
|
The magnification and rotation amounts may then be specified in the
|
||||||
|
optional MAG and ANGLE records.
|
||||||
|
The rotation angle is in counterclockwise degrees.
|
||||||
|
|
||||||
|
<P><HR><BR><H2>C.7 <A NAME="GDSArray">Array of Structures Element</A></H2><P>
|
||||||
|
|
||||||
|
For convenience, an array of structure instances can be specified with
|
||||||
|
the AREF record.
|
||||||
|
Following the optional ELFLAGS and PLEX records comes the SNAME to identify
|
||||||
|
the structure being arrayed.
|
||||||
|
Next, the optional transformation records STRANS, MAG, and ANGLE give
|
||||||
|
the orientation of the instances.
|
||||||
|
A COLROW record must follow to specify the number of columns and
|
||||||
|
the number of rows in the array.
|
||||||
|
The final record is an XY with three points: the coordinate of the
|
||||||
|
corner instance, the coordinate of the last instance in the columnar
|
||||||
|
direction, and the coordinate of the last instance in the row direction.
|
||||||
|
From this information, the amount of instance overlap or separation
|
||||||
|
can be determined.
|
||||||
|
Note that flipping arrays (in which alternating rows or columns are mirrored
|
||||||
|
to abut along the same side) can be implemented with multiple arrays that
|
||||||
|
are interlaced and spaced apart to describe alternating rows or columns.
|
||||||
|
|
||||||
|
<P><HR><BR><H2>C.8 <A NAME="GDSText">Text Element</A></H2><P>
|
||||||
|
|
||||||
|
Messages can be included in a circuit with the TEXT record.
|
||||||
|
The optional ELFLAGS and PLEX follow with the mandatory LAYER record
|
||||||
|
after that.
|
||||||
|
A TEXTTYPE record with a zero argument must then appear.
|
||||||
|
An optional PRESENTATION record specifies the font in bits 11 and 12,
|
||||||
|
the vertical presentation in bits 13 and 14 (0 for top, 1 for
|
||||||
|
middle, 2 for bottom), and the horizontal presentation in bits 15 and 16
|
||||||
|
(0 for left, 1 for center, 2 for right).
|
||||||
|
Optional PATHTYPE, WIDTH, STRANS, MAG, and ANGLE records may appear to
|
||||||
|
affect the text.
|
||||||
|
The last two records are required: an XY with a single coordinate to
|
||||||
|
locate the text and a STRING record to specify the actual text.
|
||||||
|
|
||||||
|
<P><HR><BR><H2>C.9 <A NAME="GDSNode">Node Element</A></H2><P>
|
||||||
|
|
||||||
|
Electrical nets may be specified with the NODE record.
|
||||||
|
The optional ELFLAGS and PLEX records follow and the required LAYER
|
||||||
|
record is next.
|
||||||
|
A NODETYPE record must appear with a zero argument, followed by an XY record
|
||||||
|
with one to 50 points that identify coordinates on the electrical net.
|
||||||
|
The information in this element is not graphical and does not affect the
|
||||||
|
manufactured circuit.
|
||||||
|
Rather, it is for other CAD systems that use topological information.
|
||||||
|
|
||||||
|
<P><HR><BR><H2>C.10 <A NAME="GDSBox">Box Element</A></H2><P>
|
||||||
|
|
||||||
|
The last element of a GDS II file is the box.
|
||||||
|
Following the BOX record are the optional ELFLAGS and PLEX records,
|
||||||
|
a mandatory LAYER record, a BOXTYPE record with a zero argument,
|
||||||
|
and an XY record.
|
||||||
|
The XY must contain five points that describe a closed, four-sided box.
|
||||||
|
Unlike the boundary, this is not a filled figure.
|
||||||
|
Therefore it cannot be used for IC geometry.
|
||||||
|
<P>
|
||||||
|
<HR>
|
||||||
|
<TABLE COLSPEC="L40 L40 L40 L40 L40 L40 L40 L40 L40 L40" BORDER=0><TR>
|
||||||
|
<TD><A HREF="chapb.html"><IMG SRC="../images/iconbackarrow.gif" ALT="Prev" BORDER=0></A></TD>
|
||||||
|
<TD><A HREF="chapb.html">Previous</A></TD>
|
||||||
|
<TD> </TD>
|
||||||
|
<TD><A HREF="../index.html"><IMG SRC="../images/iconcontarrow.gif" ALT="Contents" BORDER=0></A></TD>
|
||||||
|
<TD><A HREF="../index.html">Table of Contents</A></TD>
|
||||||
|
<TD> </TD>
|
||||||
|
<TD><A HREF="chapd.html">Next</A></TD>
|
||||||
|
<TD><A HREF="chapd.html"><IMG SRC="../images/iconforearrow.gif" ALT="Next" BORDER=0></A></TD>
|
||||||
|
<TD> </TD>
|
||||||
|
<TD><ADDRESS><A HREF="mailto:strubin@rulabinsky.com"><CENTER>Steven M. Rubin</CENTER></A></ADDRESS></TD>
|
||||||
|
<TD> </TD>
|
||||||
|
<TD><A HREF="http://www.staticfreesoft.com">Static Free Software</A></TD>
|
||||||
|
<TD><A HREF="http://www.staticfreesoft.com"><IMG SRC="../images/iconsfs.gif" ALT="SFS" BORDER=0></A></TD>
|
||||||
|
</TR></TABLE>
|
||||||
|
</BODY>
|
||||||
|
</HTML>
|
||||||
2357
doc/spec_2.html
Normal file
2357
doc/spec_2.html
Normal file
File diff suppressed because it is too large
Load Diff
Loading…
Reference in New Issue
Block a user