<@U016EM8L91B> After GDS write completed (over 11 ...
# magic
m
@User After GDS write completed (over 11 hours of total flow time) and during LEF generation, magic exited with a
kill signal
. This occurred in the docker and the magic version is 8.3.87. I've provided the context of the log below. If there's anything else I can provide (or you want me to create a GitHub issue), let me know.
Writing cell sky130_fd_sc_hd__buf_12
[INFO]: GDS Write Complete
[INFO]: Writing abstract LEF
Generating LEF output /openLANE_flow/designs/decred_nonblock/runs/8mFP50DENS50STRAT1_20ns/results/magic/decred_nonblock.lef for cell decred_nonblock:
Diagnostic:  Write LEF header for cell decred_nonblock
Diagnostic:  Writing LEF output for cell decred_nonblock
[ERROR]: during executing: "magic -noconsole -dnull -rcfile /home/dracex/PDK_ROOT/sky130A/libs.tech/magic/sky130A.magicrc /openLANE_flow/scripts/magic.tcl </dev/null |& tee >&@stdout /openLANE_flow/designs/decred_nonblock/runs/8mFP50DENS50STRAT1_20ns/logs/magic/magic.log"
[ERROR]: Exit code: 1
[ERROR]: Last 10 lines:
child killed: kill signal
[ERROR]: Please check magic  log file
[ERROR]: Dumping to /openLANE_flow/designs/decred_nonblock/runs/8mFP50DENS50STRAT1_20ns/error.log
while executing
"try_catch magic  -noconsole  -dnull  -rcfile $::env(MAGIC_MAGICRC)  $::env(SCRIPTS_DIR)/magic.tcl  </dev/null  |& tee $::env(TERMINAL_OUTPUT) $::env(m..."
(procedure "run_magic" line 14)
invoked from within
"run_magic"
(procedure "run_non_interactive_mode" line 27)
invoked from within
"run_non_interactive_mode {*}$argv"
invoked from within
"if { [info exists flags_map(-interactive)] || [info exists flags_map(-it)] } {
puts_info "Running interactively"
if { [info exists arg_values(-file)..."
(file "./flow.tcl" line 168)
a
How large is your design? It seems like it ran out of memory and swap since it received a kill signal?
m
yosys_1.stat.rpt shows number of cells at 377k. Since then I have tried a smaller version of the design at 283k cells and it still fails with the same error. The VM I'm running in has 16G of RAM.
t
@Ahmed Ghazy: Openlane is using "cif *hier write disable" for all digital standard cell layouts? Because assuming so, the GDS output should be very fast and very low overhead.
a
@Tim Edwards: Yes, that's the default for std cell layouts. @Matt Aamold: Are you using the latest on the develop branch?
m
@Ahmed Ghazy I'm using develop branch of openlane as of Nov 30. Have changes been made since then that you think would resolve this?
a
Not really; I only added
cif *array write disable
besides the existing https://github.com/efabless/openlane/blob/e63096fec826f1bad03700a26cb6c6abb6a7c5c7/scripts/magic.tcl#L75.
Could you open an issue and share the routed DEF and
merged.lef
files?
t
@Ahmed Ghazy: "cif *array" will do nothing because openlane doesn't generate arrays. Otherwise, the script looks okay so we'll have to try to duplicate the problem and see what's causing it.
m
@Ahmed Ghazy Sure, could you point me to where these files would be in the "runs" directory (e.g., results/magic/*)?
Also, which github repo should I open this issue in?
a
results/routing/design_name.def
and
tmp/merged.lef
. You can open it on openlane's GH repo for now.
m
What's the best way to share a large file (DEF) that is about 462MB? The LEF is only about 2MB.
Maybe compress it and push it on my GH repo?
a
Yea, that sounds good.
m
a
@Matt Aamold: It took around 30 mins to generate both LEF and GDS using magic
8.3.91
, which will be the default in a bit in openlane. It used around 9 GB of memory most of the time. You don't have to re-run the whole flow if you want to retry this; you could use the interactive mode
flow.tcl -interactive -design decred_nonblock -tag 8mFP50DENS50STRAT1_20ns
and then use
run_magic
.
m
I'll try that. Thanks for looking into this.