"port" and "noport" in the cifoutput section to distinguish
between layer:purpose pairs for port text vs. other kinds of
text. This allows a closer correspondence between GDS read and
write. Note that the port writing is currently only in the GDS
write routine, not in the CIF routine.
additional functionality for ports in GDS format. This has been
tested with a techfile encoding pin types on a different purpose
than the metal layer drawing purpose. The label rectangle is
correctly written to the GDS output as geometry on the pin
purpose layer, and the same layer gets read back in from the GDS
file and translated back into the label rectangle. Port order
is maintained.
geometry attached to a label in GDS using specific layer:purpose
pairs. The additional code maintains the order of ports when
writing out text to GDS, and attempts to attach geometry to labels
when the geometry is defined on the same layer:purpose pair as
the text, and the cifinput style declares the purpose to be a
port label.
This allows text appearing on a specific GDS layer:purpose pair
to be interpreted as a port. This does not quite match the
intended behavior of such layers, since it is implied that any
layer geometry coincident with the text should form the area of
the port, which is not (yet) handled. Also, it is presumably
implied that the port order matches the order in which text
appears in the GDS stream, but magic does not preserve this
order when re-writing any GDS output.
an error message when reading uses from a .mag file. Also modified
the GDS write routine to provide an error message when an abstract
view points to a GDS file but the GDS file cannot be found.
both an abstract view (i.e., comes from a LEF file or otherwise
has been marked with the LEFview property) and a GDS_FILE
property expects to insert the contents of GDS_FILE into the GDS
output stream minus header and trailer, and with all internal
cells renamed by prefixing them with the top-level cell name to
avoid naming conflicts.
from "gds polygon subcell". Previously both polygons and paths
were put into subcells named polygonXXXXX (substitute numbers
for XXXXX). Now polygons go into cells named polygonXXXXX and
paths go into cells named pathXXXXX. This makes it easier to
keep track of the original path. NOTE: The path centerline
should be kept as a cell property in this case, and the path
options like endcap style can also be held as properties. The
polygon boundary should be treated similarly.
development had been halted since it was first created back in April.
Version 8.2 is now the official development version, with the first
development push to create a Cairo graphics interface.
Tim Edwards