I checked out the openlane develop branch a couple...
# openlane
m
I checked out the openlane develop branch a couple hours ago, but still having errors with the
or_opendb.tcl
script erroring out. When I implement my design at the
user_proj_example
level, and run
make
on it from the
caravel/openlane
directory, I'm still getting several
Warning: detailed placement failed on _44889_
messages followed by
Warning: Overlap check failed (136).
followed by the
or_opendb.tcl
fatally erroring out. Are the openlane devs aware of this or should I open an issue on github? Or am I doing something incorrect here?
a
are you using any hard macros?
i ran into this a lot when i had a mix of big hard macros and some synthesised cells. @tnt has a script that will read the lef and move the cells off the macros so that detailed placement (
opendp
) will actually work. it takes a bit of guesswork but with some hair pulling it will work.
m
No, I'm not using any hard macros.
a
@Matt Aamold: you simply need to change
CELL_PAD
,
FP_CORE_UTIL
, and
PL_TARGET_DENSITY
. Specially the last two. Here is a note I added to the caravel repo and will be included in the release notes when rc5 is out.
Copy code
NOTE: rc5 (current openlane develop) and rc4 (current openlane master) are using two different concepts of cell padding. rc4 is modifying the LEF, while rc5 is relying on openroad to handle the cell padding. Also, rc4 is using the standalone version of openDP while rc5 is using the one integrated in the openroad app. This affects the concept of PL_TARGET_DENSITY and while in rc4 it was preferred to have PL_TARGET_DENSITY=(FP_CORE_UTIL-(5~10)/100). Now, in rc5 it is preferred to be PL_TARGET_DENSITY=(FP_CORE_UTIL+(1~5)/100). FP_CORE_UTIL should be relaxed as well as it became more representative of the actual core utilization, which wasn't so much the case earlier. So, the perception of these two variables as well as CELL_PAD changed between rc4 and rc5 which necessitates a change in the configurations of almost every single design. CELL_PAD should be 4~6 for the skywater libraries in rc5 unlike rc4 which was 8.This will be included in the release notes when rc5 is released as well as the openlane wiki.
Either way, you'll probably need to reduce the FP_CORE_UTIL and change the PL_TARGET_DENSITY to reflect that change.
m
@Amr Gouhar Ok thanks. I was already specifying
PL_TARGET_DENSITY
with a value of
.15
, but I wasn't specifying either
CELL_PAD
or
FP_CORE_UTIL
. I've been able to get past the fatal error from
or_opendb.tcl
by specifying
CELL_PAD
to
4
and
FP_CORE_UTIL
to
20
. I'm getting a fatal error during fastroute now, but I'll leave that as a different thread. I'd like to understand what the deficiency was when not specifying
CELL_PAD
or
FP_CORE_UTIL
(i.e., what their default values were) so I can tune these values better. Are there "typical" values for
FP_CORE_UTIL
?
a
@Matt Aamold: Usually, the more cells in your design, the more likely that it would get congested, the less you need to set
FP_CORE_UTIL
.
CELL_PAD
is std_cell specific thing to keep a space around the cell to easily access the pins while routing (so the higher the
CELL_PAD
the less the actual utilization). Typically for rc5/develop
CELL_PAD
for the skywater libraries should be 4~6. I think you might find this useful as well. Most of the time the solution to all congestion and failed placement errors is to reduce the
FP_CORE_UTIL
and then change
PL_TARGET_DENSITY
to reflect that. https://github.com/efabless/openlane/blob/develop/regression_results/benchmark_results/SW_HD.csv This sheet, should give you a sense of what to set FP_CORE_UTIL and PL_TARGET_DENSITY for a specific design based on its proximity in the cell count to any of these 40 designs.