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.
Tim Edwards
Roman-Parise