Hmm, does anyone have had experience with dealing with errors of the type

[ERROR]: There are illegal overlaps (e.g., routes over obstructions) in your design.

[ERROR]: See /path/to/project/openlane/user_project_wrapper/runs/user_project_wrapper/logs/finishing/27-ext2spice.feedback.txt for more.

at the last steps of the overall hardening flow (for the wrapper)? The said file contains many lines of the following form:

box 80124 41296 80875 41347

feedback add "Illegal overlap between obsm1 and metal1 (types do not connect)" medium

When looking at the generated gds file in klayout, depending on the unit used in that the feedback.txt file, either there is nothing at that place, or the position is inside an SRAM macro. What would make sense to look for for fixing the problem(s)?

@User Divide the units by 200. I believe these types of errors can occur when the obstructions and metal are on different hierarchies. Also if the LEF does not match the actual layout.

@User Thanks. I did not define any obstructions in the wrapper project, so I'm not sure if they can be at different hierachies. I just noticed that the lines of the file are executable magic commands. There, the place is indeed inside an OpenSRAM macro. (the 1rw1r_32x256_8 to be specific)

Do you have a screen shot (showing met1 and obsm1)?

I am pretty sure caravel wrapper used to have a metal obstructions defined in config.tcl. Do you have any metal obstructions, particularly met1?

So this is the best screenshot that I can build. The light pink stripes are metal1, the heaviner pink one is metal5. There doesn't appear to an obstruction layer that I can switch on or off in magic.

obstruction are only visible in lef/def and as far as I am aware are not visible in magic

@User Thanks for your hints. "obsm1" appears only in runs/user_project_wrapper/results/finishing/user_project_wrapper.lef.mag", but I can't tell which step of openlane that is generated because the file is not mentioned in openlane's console output anywhere. The input LEFs for the Sky130 PDK SRAM blocks list obstructions - basically the whole macro is blocked for metal 1. I've tested if moving the first SRAM macro (in the "macros.cfg" file) also moves the obstruction, and indeed it does. The config.tcl looks as follows:

set ::env(PDK) "sky130A"

set ::env(STD_CELL_LIBRARY) "sky130_fd_sc_hd"

# YOU ARE NOT ALLOWED TO CHANGE ANY VARIABLES DEFINED IN THE FIXED WRAPPER CFGS

source $::env(CARAVEL_ROOT)/openlane/user_project_wrapper/fixed_wrapper_cfgs.tcl

# YOU CAN CHANGE ANY VARIABLES DEFINED IN THE DEFAULT WRAPPER CFGS BY OVERRIDING THEM IN THIS CONFIG.TCL

source $::env(CARAVEL_ROOT)/openlane/user_project_wrapper/default_wrapper_cfgs.tcl

set script_dir [file dirname [file normalize [info script]]]

set ::env(DESIGN_NAME) user_project_wrapper

#section end

# User Configurations

## Source Verilog Files

set ::env(VERILOG_FILES) "\

$::env(CARAVEL_ROOT)/verilog/rtl/defines.v \

$script_dir/../../verilog/rtl/user_project_wrapper.v"

## Clock configurations

set ::env(CLOCK_PORT) "user_clock2"

set ::env(CLOCK_NET) "CONTROL_LOGIC.clk"

set ::env(CLOCK_PERIOD) "10"

## Internal Macros

### Macro PDN Connections

set ::env(FP_PDN_MACRO_HOOKS) "\

prj vccd1 vssd1 \

SRAM1 vccd1 vssd1 \

SRAM12 vccd1 vssd1"

### Macro Placement

set ::env(MACRO_PLACEMENT_CFG) $script_dir/macro.cfg

### Black-box verilog and views

set ::env(VERILOG_FILES_BLACKBOX) "\

$::env(CARAVEL_ROOT)/verilog/rtl/defines.v \

$script_dir/../../verilog/rtl/user_project.v \

$script_dir/../../verilog/rtl/monitor.v \

$::env(PDK_ROOT)/sky130A/libs.ref/sky130_sram_macros/verilog/sky130_sram_2kbyte_1rw1r_32x512_8.v \

$::env(PDK_ROOT)/sky130A/libs.ref/sky130_sram_macros/verilog/sky130_sram_1kbyte_1rw1r_32x256_8.v"

set ::env(EXTRA_LEFS) "\

$script_dir/../../lef/user_project.lef \

$::env(PDK_ROOT)/sky130A/libs.ref/sky130_sram_macros/lef/sky130_sram_2kbyte_1rw1r_32x512_8.lef \

$::env(PDK_ROOT)/sky130A/libs.ref/sky130_sram_macros/lef/sky130_sram_1kbyte_1rw1r_32x256_8.lef"

set ::env(EXTRA_GDS_FILES) "\

$script_dir/../../gds/user_project.gds \

$::env(PDK_ROOT)/sky130A/libs.ref/sky130_sram_macros/gds/sky130_sram_2kbyte_1rw1r_32x512_8.gds \

$::env(PDK_ROOT)/sky130A/libs.ref/sky130_sram_macros/gds/sky130_sram_1kbyte_1rw1r_32x256_8.gds"

set ::env(RT_MAX_LAYER) {met4}

# disable pdn check nodes becuase it hangs with multiple power domains.

# any issue with pdn connections will be flagged with LVS so it is not a critical check.

set ::env(FP_PDN_CHECK_NODES) 0

# The following is because there are no std cells in the example wrapper project.

set ::env(SYNTH_TOP_LEVEL) 1

set ::env(PL_RANDOM_GLB_PLACEMENT) 1

set ::env(PL_RESIZER_DESIGN_OPTIMIZATIONS) 0

set ::env(PL_RESIZER_TIMING_OPTIMIZATIONS) 0

set ::env(PL_RESIZER_BUFFER_INPUT_PORTS) 0

set ::env(PL_RESIZER_BUFFER_OUTPUT_PORTS) 0

# set ::env(MACRO_PLACE_HALO) 4

# set ::env(MACRO_PLACE_CHANNEL) "100 100"

#Reduction in the routing capacity of the edges between the cells in the global routing graph. Values range from 0 to 1.

#1 = most reduction, 0 = least reduction

set ::env(GLB_RT_LAYER_ADJUSTMENTS) 0.8,0.8,0.7,0,0,0

# Not too many iterations

set ::env(DRT_OPT_ITERS) 10

set ::env(SYNTH_USE_PG_PINS_DEFINES) "USE_POWER_PINS"

set ::env(VDD_NETS) "vccd1 vccd2 vdda1 vdda2"

set ::env(GND_NETS) "vssd1 vssd2 vssa1 vssa2"

set ::env(DIODE_INSERTION_STRATEGY) 0

set ::env(FILL_INSERTION) 0

set ::env(TAP_DECAP_INSERTION) 0

set ::env(CLOCK_TREE_SYNTH) 0

And as far as the versions are concerned: OpenLane is version 2022.02.23_02.50.41 - OpenPDK commit should be 7519dfb04400f224f140749cda44ee7de6f5e095 (according to the Makefile).

What does the pdn hook do? I would assume it's the reason for this metals. Idk what to do next. I would go to openlane channel first and if it does not help, report it to openlane team and see what they say.

@User From https://openlane.readthedocs.io/en/latest/configuration/README.html

Specifies explicit power connections of internal macros to the top level power grid. Comma separated list of macro instance names and power domain vdd and ground net names: <instance_name> <vdd_net> <gnd_net>
(Default: macros are connected to the first power domain)

Yeah I understand that, but does it mean it's routing these metal strips on top of the sram? If it does mean it, then this is the cause I would assume.

@User On the magic

Options

menu, unselect

Toolbar Hide Locked

. The

obsm1

locked layer should be to the right of the unlocked

m2contact

.

@User Thanks for that hint. When loading the "results/finishing/user_project_wrapper.lef.mag" file in addition to the GDS file in magic, it looks like the obsm1 region spans the complete caravel user area. Otherwise nothing shows up in magic. @User I've just checked that specifying or not specifying the PDN_HOOKS makes no difference. Specifying them was done in an attempt to fix the "[WARNING]: All internal macros will not be connected to power." warnings that show up. However, I'm suspecting now that they do not actually mean what they say, but rather there is one warning for each voltage pair in the user space that is not used by the design. And then getting three of these warnings is fine if only vccd1/vssd1 are used.

@User Could you check if in fixed wrapper config you have obstruction over met1?

@User There is no "GLB_RT_OBS" defined in my own config.tcl, which is the only type of obstruction that I'm aware of that can be set. The fixed_wrapper file has not been changed by me and look as follows: # DON'T TOUCH THE FOLLOWING SECTIONS set script_dir [file dirname [file normalize [info script]]]

# This makes sure that the core rings are outside the boundaries

# of your block.

set ::env(MAGIC_ZEROIZE_ORIGIN) 0

# Area Configurations. DON'T TOUCH.

set ::env(FP_SIZING) absolute

set ::env(DIE_AREA) "0 0 2920 3520"

set ::env(RUN_CVC) 0

# Pin Configurations. DON'T TOUCH

set ::env(FP_PIN_ORDER_CFG) $script_dir/pin_order.cfg

set ::unit 2.4

set ::env(FP_IO_VEXTEND) [expr 2*$::unit]

set ::env(FP_IO_HEXTEND) [expr 2*$::unit]

set ::env(FP_IO_VLENGTH) $::unit

set ::env(FP_IO_HLENGTH) $::unit

set ::env(FP_IO_VTHICKNESS_MULT) 4

set ::env(FP_IO_HTHICKNESS_MULT) 4

# Power & Pin Configurations. DON'T TOUCH.

set ::env(FP_PDN_CORE_RING) 1

set ::env(FP_PDN_CORE_RING_VWIDTH) 3.1

set ::env(FP_PDN_CORE_RING_HWIDTH) 3.1

set ::env(FP_PDN_CORE_RING_VOFFSET) 14

set ::env(FP_PDN_CORE_RING_HOFFSET) $::env(FP_PDN_CORE_RING_VOFFSET)

set ::env(FP_PDN_CORE_RING_VSPACING) 1.7

set ::env(FP_PDN_CORE_RING_HSPACING) $::env(FP_PDN_CORE_RING_VSPACING)

set ::env(FP_PDN_VWIDTH) 3.1

set ::env(FP_PDN_HWIDTH) 3.1

set ::env(FP_PDN_VSPACING) [expr 5*$::env(FP_PDN_CORE_RING_VWIDTH)]

set ::env(FP_PDN_HSPACING) [expr 5*$::env(FP_PDN_CORE_RING_HWIDTH)]

set ::env(VDD_NETS) [list {vccd1} {vccd2} {vdda1} {vdda2}]

set ::env(GND_NETS) [list {vssd1} {vssd2} {vssa1} {vssa2}]

set ::env(SYNTH_USE_PG_PINS_DEFINES) "USE_POWER_PINS"

In your previous screen shot, there was a short-wide white rectangle in the middle. This may be your obsm1 which is overlapping m1. It may be at a hierarchy below the top level so that the obsm1 over the whole area is not relevant.

Ah, that thin white rectangle was the box

box 80124 41296 80875 41347

for the entry

feedback add "Illegal overlap between obsm1 and metal1 (types do not connect)" medium

from

/runs/user_project_wrapper/logs/finishing/27-ext2spice.feedback.txt

- I figured that that file contained commands that can be executed by magic.

So no obsm1 there?

Very weird. I found that in the LEF file for the SRAM macro, there is indeed a "met1" entry in the "OBS" section -- essentially the whole macro space is blocked on that layer, which makes sense as the layer is probably used within the macro. The first screenshot of mine shows five thin horizontal pink stripes, which are also on met1 and that are put on top of the macro, so this looks indeed incorrect. These stripes span the whole die area and appear to be some kind of fill pattern.