Segmentation fault in openroad about openlane

[tgingold]

Ah thanks. I wrongly checkout the master of sky130_fd_sc_hd. Now it works.

Thank you again.

[agorararmard]

@tgingold Can you share any of the errors (segfault and what came before it)? At what part of openroad does it break? Did you rebuild the pdk to use rc3?

[ax3ghazy]

@tgingold: The relevant variables should be found under config.tcl under the run directory if you'd like to source them and run the openroad binary under a debugger.

[tgingold]

That's during cts (for spm):

[INFO]: Running TritonCTS...
[ERROR]: during executing: "openroad -exit /openLANE_flow/scripts/openroad/or_cts.tcl"
[ERROR]: Last 10 lines:
Warning: Liberty cell sky130_fd_sc_hd__xor3_2 pin VPB missing from LEF macro
Warning: Liberty cell sky130_fd_sc_hd__xor3_4 pin VNB missing from LEF macro
Warning: Liberty cell sky130_fd_sc_hd__xor3_4 pin VPB missing from LEF macro
Notice 0: 
Reading DEF file: /openLANE_flow/designs/spm/runs/29-09_18-06/results/placement/spm.placement.def
Notice 0: Design: spm
Notice 0:     Created 36 pins.
Notice 0:     Created 636 components and 3304 component-terminals.
Notice 0:     Created 405 nets and 1120 connections.
Notice 0: Finished DEF file: /openLANE_flow/designs/spm/runs/29-09_18-06/results/placement/spm.placement.def

[ERROR]: Please check openroad  log file
[ERROR]: Dumping to /openLANE_flow/designs/spm/runs/29-09_18-06/error.log

    while executing
"try_catch openroad -exit $::env(SCRIPTS_DIR)/openroad/or_cts.tcl"
    (procedure "run_cts" line 13)
    invoked from within
"run_cts"
    (procedure "run_non_interactive_mode" line 14)
    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 "./flow.tcl" line 160)

And yes, I have updated the pdk too.

[agorararmard]

Could you share the full run directory?

[tgingold]

Here is the zip.

spm-bug.zip

[agorararmard]

I can see nwell and pwell layers in the LEF file, which indicates that something went wrong with the pdk generation. So, can you check the commit hashes for open_pdks and skywater-pdk as well as the magic version you have installed locally?

[tgingold]

$ magic --version
8.3.61

[skywater-pdk]$ git describe
v0.0.0-187-g5cd70ed

[open_pdks]$ git describe --long
1.0.40-0-g48db3e1

nwell and pwell are not present in libraries/sky130_fd_sc_hd/latest/tech/sky130_fd_sc_hd.tlef. Is it expected ?

[latest]$ git describe
v0.0.2-32-g300eb6f

[tgingold]

I will retry to generate the pdk.

[tgingold]

No success.

Can you briefly explain how the nwell and pwell are expected to be handled by open_pdk ? Thanks!

[agorararmard]

@tgingold, I'm not sure if this is caused by open_pdks or the fact that the commit of the skywater-pdk that you have doesn't add up with the version of the sky130_fd_sc_hd/latest.
if you have v0.0.0-187-g5cd70ed, then the commit hash of the sky130_fd_sc_hd should be 74c2ab

Did you try re-cloning the skywater-pdk from scratch?

Also, to answer your question, they are in the cells lef, not the tech lef (they shouldn't exist in both).