a cell instance name not related to an array moved a variable that
was used later in the routine to the inside of an if block,
effectively making that variable undefined in most cases.
handles diodes or other devices with source/drain on planes other
than the plane of the device type. This no longer requires that
the non-connecting type be in any given terminal position. The
device type boundary is surveyed for all types, connecting or
overlapping, and at least one of each required type must be present.
format with multiple devices per magic tile type. The code was left
incompatible with diodes defined with one terminal as substrate
(and therefore no source/drain-like types connecting to the device
type). This has been fixed.
item that was never properly validated. Corrected the root of the
problem, which was an attempt to deallocate memory that had never
been allocated in the first place.
commit, found that DBTreeFindUse fails to find such uses because
it strips the array delimiters off the name. Fixed the routine
although the routine really should be checking if the use is a
1- or 2- dimensional array and stripping off only the components
expected. The current code will probably fail for cell uses
that have brackets in the name AND are arrayed. Fortunately
this search routine does not appear to be used frequently or in
any critical database functions like netlisting.
all types specified in the "substrate" statement, split such types
into those on the declared well plane, and everything else. Any
types on the well plane are searched as before. Types not on the
well plane (e.g., psd on active) are searched and added to the
substrate node *only* if overlapping nothing on the well plane.
This allows a type such as "psd" to be used on, e.g., both space
(substrate) and deep pwell, but only be extracted as part of the
substrate when found over space. Note that if there is NO
implicit substrate, the substrate connections will always be
found through the usual connection rules.
to be more robust and not depend on the ordering of the devices in
the techfile. The extraction method now keeps a mask of which
properties of the device (source/drain types, substrate type,
identifier type) have been found, and will look only for device
records that match what is known about the device. Added a device
identifier record which is the last record before parameters if the
record begins with "+". This allows marker layers to be placed
over a device such that it will extract with a different type.
This helps reduce the complexity of the techfile and allows
certain specialized devices like RF or ESD to be identified without
a separate layer type for the device.
was previously (and erroneously) lumped with PLACED and FIXED which
take a position argument afterward. Note that this fix allows the
DEF file to be read without error but does not have the (presumably
desired) behavior of parsing SITE information from the LEF file and
ROWS information from the DEF file and giving each unplaced component
an arbitrary but legal position. That would require a significant
amount of additional coding work.
while reading DEF. To preserve names as much as possible, such
names are now kept. To avoid problems, EFbuild.c and ext2hier
behavior has been changed to only parse entries in a .ext file as
instance arrays if the array notation follows the specific syntax
of [ax:bx:cx][ay:by:cy], letting all other uses of brackets pass
through unaffected.
instead created a dependency on database.h for compiling any
source file. This should (I hope) avoid conflicts when running
"make" with the "-j" option for parallel compilation.
sure if this is the best policy. The brackets should be okay
but interfere with ext2spice when it reads them from the .ext
file and decides that they refer to arrays. May be a better
way to handle this.
forms of syntax found in the LEF/DEF spec up to version 5.8. Handles
vias formed by parameter and a number of syntax variations that mess
up the usual parsing. Corrected an error in the calculation of wire
extensions when wires are given with three coordinates.
the compiler. Some are obscure functions (plot verstatec hasn't
been used in years) but others (like SPICE distributed junctions)
are potentially significant sources of unexpected crashes on
systems that don't zero uninitialized memory.
64 because I overran the 64 array with too many resistclasses in
a techfile. This really should be dynamically allocated; this
requires parsing the line to count tokens and reallocating as
needed (to be done).
discovered that not all LEF/DEF rectangle coordinates are in
canonical order. Took the opportunity to update the LefError()
routine with an additional argument so that it can separate
errors, warnings, and informational messages, and will correctly
state whether the output is for a LEF or DEF read operation.
addition to subcells, paint, and labels. Otherwise problems arise
if a cell is read from LEF followed by GDS; the GDS view overwrites
the LEF but the property "LEFview" remains and causes problems when
writing GDS output subsequently.
option "labels ... cellid" to handle some vendor files where
apparently to get around the 30-character cell name limit, the
actual cellname is encoded on a text layer. Added new cifop
"boundary" (no arguments) for cases where a cell abutment box
is encoded on a GDS layer; this now translates the bounding
box to the FIXED_BBOX property, as is done with the LEF bounding
box. Also corrected the property set function to free existing
property value allocated memory when overwriting a property with
a new value.
were made where contacts are placed when shifting up on metal
layer but not made for the reverse case. Also corrected one
inconsistency with non-minimum width wires.
the same interpretation as the scalefactor for the DRC section:
Values in the section are interpreted as lambda divided by the
scalefactor. That allows the wiring values to be real units such
as nanometers and avoid problems with fractional lambda values.
lengths exceeding the maximum GDS name length (32 characters),
truncate by removing all but the last 32 characters, instead of
the previous behavior which was to remove all but the first 32
characters. The last 32 characters are far more likely to be
unique than the first 32, given that the usual reason for extra-
long names is the concatentation of hierarchical names.
Tim Edwards
Roman-Parise