Which are not overlapping at all. Now if you vary ...
# openlane
a
Which are not overlapping at all. Now if you vary the utilization slightly, the layout size will also vary slightly such that the tap cell on the left wouldn't get placed so close the endcap cell.
u
Got it, are these placed based on distance rule? Can I provide offset? Any hint for packing a test case?
a
Yup, tap distancing is set to 14um (the actual max distancing rule being 15 um). Nope, you cannot provide an offset. As far as I can see, it happens when the width of the die is close close to an integer multiple of the above tap distance. I'd say if you ran into one of those cases, simply pack the latest DEF file and a simple openroad tcl script that reads it and runs
check_placement -verbose
.
u
I just fixed my klayout and I’m trying to take a look to my design.floorplan.def, however klayout can’t resolve the dependencies, it seems klayout.lyt doesn’t have any references to the <MERGED>.lef file for the library, any way to pass that?
a
You can either load the lef file with each DEF file you're trying to view (go to File -> Import -> DEF/LEF and select both files; you can find the
merged.lef
lef under the
tmp
directory of any run). Or you can set up klayout to read the tech LEF and cells LEF automatically if you go to Tools -> Manage Technologies -> <Sky130A> -> Reader Options -> LEF/DEF, then select the tech LEF and cells LEF found under
libs.ref
of your
open_pdks-sky130A
installation.
🙌 1
u
I guess since this is actually library specific and not tech specific I’ll go by loading them together for now, I was having trouble with that due to multiple END LIBRARY statements on the merged version, thanks!
🙌 1