probably needs revisiting, because "lef write" and "lef writeall"
need handling to generate the PROPERTYDEFINITIONS block for the
PROPERTY entries to be correct.
layers (apart from the fact that contacts are output as magic's
contact layer representation, and not as cuts; this still needs to
be handled properly).
I missed the LAYER value and the geometry was one level to high.
Previous;
```
PORT
LAYER li1 ;
RECT 1.145000 1.075000 1.690000 1.275000 ;
RECT 3.720000 1.075000 4.490000 1.275000 ;
LAYER met1 ;
RECT 1.105000 1.260000 1.395000 1.305000 ;
RECT 3.765000 1.260000 4.055000 1.305000 ;
```
After;
```
PORT
LAYER li1 ;
RECT 1.145000 1.075000 1.690000 1.275000 ;
RECT 3.720000 1.075000 4.490000 1.275000 ;
LAYER met1 ;
RECT 1.105000 1.260000 1.395000 1.305000 ;
RECT 3.765000 1.260000 4.055000 1.305000 ;
```
areas and writes ANTENNAGATEAREA and ANTENNADIFFAREA values.
(2) Determines "USE POWER" or "USE GROUND" from label names
matching Tcl variables $VDD and $GND, if the USE has not been
registered as a cell property (knowning the use allows magic
to avoid writing an ANTENNADIFFAREA for power rails, although
doing so should not be an issue).
a LEF macro that has parentheses around the coordinates. Weirdly,
this is requires by the LEF/DEF spec, but is rarely if ever seen
in actual LEF files. Go figure.
because otherwise all pins will flag metal-to-obstruction spacing
within the cell if the cell is wide enough that the obstruction
layer satisfies the width requirement for the rule. It is too
complicated to try to find specific places where the wide spacing
might not be needed. Potentially this could be a problem for
technologies that define a number of graded wide-spacing rules,
as the largest-width rule is always used now by "lef write -hide",
and the largest-width rule could theoretically allow enough space
to route through, which would cause a short that cannot be
detected. That would be a pathological case that may not show up
in practice.
labels by expanding a zero area label rectangle, but then if "select
chunk" returns nothing, it sets the area to the zero area label
rectangle instead of the expanded one that it just created. This
is the reason that "lef write" is producing pins with no geometry
in the LEF file output.
Conflicts:
VERSION
Merged recent changes from master back into bplane, as the efficiency of
bplane for doing extraction on large layouts is unquestionably better.
Fixed the implementation of DBMoveCell() for bplane. Corrected an error
in the bplane version of dbScaleCell() that enumerates cell uses but
does not free the list.
as an optional argument (which it is), and so defaults were not
applied, potentially leading to the wrong number of rows/columns in
a generated via if ROWCOL is not present in the DEF file.
of the pin port geometry and using those areas to create the
spacing between them and the obstruction layer. Otherwise, the
existing method used different databases (source vs. flattened) to
find the pin area, and they did not always agree on the exact
dimensions, leading to spacing errors within the LEF view.
Conflicts:
VERSION
calma/Depend
cif/Depend
cmwind/Depend
commands/Depend
database/Depend
dbwind/Depend
debug/Depend
drc/Depend
ext2sim/Depend
ext2spice/Depend
extflat/Depend
extract/Depend
garouter/Depend
gcr/Depend
graphics/Depend
grouter/Depend
irouter/Depend
lef/Depend
lisp/Depend
mzrouter/Depend
netmenu/Depend
plot/Depend
plow/Depend
resis/Depend
router/Depend
select/Depend
sim/Depend
tcltk/Depend
textio/Depend
tiles/Depend
utils/Depend
windows/Depend
wiring/Depend
Merged recent changes from master branch into bplane branch. Testing the
bplane implementation which has about a 5x improvement in extraction times
for large layouts, which is significant enough to move ahead with the bplane
implementation; however, the bplane implementation has not been thoroughly
vetted yet, so it will remain a branch until such time that it has been
validated.
Tim Edwards
Tim 'mithro' Ansell