With caravel and openalne mpw-one-b, the execution of our flow lasts for a veeery long time (~20h) and the terminal is freezed on:

[INFO]: Writing abstract LEF                                                                     
Generating LEF output /project/openlane/user_project_wrapper/runs/user_project_wrapper/results/magic/user_project_wrapper.lef for cell user_project_wrapper:                                      
Diagnostic:  Write LEF header for cell user_project_wrapper                                      
Diagnostic:  Writing LEF output for cell user_project_wrapper 
...
Warning:  Parent cell lists instance of "sky130_fd_sc_hd__inv_4" at bad file path /project/openlane/user_project_wrapper/runs/user_project_wrapper/results/magic/sky130_fd_sc_hd__inv_4.mag.
The cell exists in the search paths at /home/baywatcher/projects/shuttle/open_mpw_precheck/pdk/sky130A/libs.ref/sky130_fd_sc_hd/maglef/sky130_fd_sc_hd__inv_4.mag.
The discovered version will be used.
Warning:  Parent cell lists instance of "sky130_fd_sc_hd__a2111o_4" at bad file path /project/openlane/user_project_wrapper/runs/user_project_wrapper/results/magic/sky130_fd_sc_hd__a2111o_4.mag.
The cell exists in the search paths at /home/baywatcher/projects/shuttle/open_mpw_precheck/pdk/sky130A/libs.ref/sky130_fd_sc_hd/maglef/sky130_fd_sc_hd__a2111o_4.mag.
The discovered version will be used.
Diagnostic:  Scale value is 0.005000

The process-viewer shows a magicdnull process with a reasonable usage of CPU and memory. Our machine is pretty powerfull. Did anyone wait this long? Is this normal behaviour?

Magic can take a very long time writing out GDS while checking hierarchical interactions in a standard cell layout. If your design is all digital, I recommend using "gds *hier write disable" before "gds write" so that it does not try to resolve hierarchical interactions (since by definition, standard cells are designed to just sit next to each other without creating DRC issues). That can actually make the difference between a 20 hour GDS write and a 2 minute GDS write. For a standard cell design that takes up the majority of the user space, a > 24 hour write time (without disabling the hierarchy checks) would not surprise me.

In openlane that could be done by setting

MAGIC_DISABLE_HIER_GDS

to 1 in config.tcl, right? Though that also does "cif *array write disable"

Oh, okay, I was not aware of the openlane setting. Thanks for mentioning it. The "cif *array write disable" does the same thing except that arrays are handled slightly differently than otherwise. Standard cell digital layouts won't have arrays, so it's irrelevant whether it's turned on or not.

Thanks, @Tim Edwards. But this is LEF write-out, right?

Hmm. . . not sure. LEF writing should not take very long. The output is buffered and it's possible that the script has gone on to something else while the "lef write" output was the last thing that got flushed from stdout. There are ways to make a LEF write take a long time but even then I would not expect 20 hours.

Thanks.

I found the setting by grepping through the openlane rc6 sources

(abstract) LEF is taking both lots of time and memory here 😕

@tnt since the full LEF for user_project_wrapper won't be used (`make ship`used magic to join the layouts directly) you can set MAGIC_GENERATE_LEF to 0. I am also setting RUN_CVC to 0 and RUN_SPEF_EXTRACTION to 0

Yeah, that's what I just tried (setting to 0).