Current issue is

feedback add "Illegal overlap between obsv2 and metal2 (types do not connect)" medium

. There are a bunch at the point where the autorouter connected to pins of the macro but looking at the GDS there isn't anything wrong there.

Magic stores layers in planes. In a plane, no 2 layers can overlap. That’s why magic shows diffusion, poly, and gates as different layers. On the metal2 plane obsv2 and metal2 can not overlap. This sometimes happens if you split the hierarchy for a device or connection. For example, covering the whole design with obsv2 at the top level.

Ok, but I'm just instantiating the macro in verilog and letting the auto router connect it, and this is the macro from the PDK as-is.

@Tim Edwards Is this an ignorable message in magic?

Sounds like the autorouter used a different LEF view than the "maglef" cell in magic. . . although they're supposed to be the same (the "maglef" is created by reading the LEF file into magic). Generally speaking, large blocks like SRAM have a very abstracted LEF view that hides all the internal details of the cell under large obstruction shapes covering the cell, and only exposes the ends of the pins. If the autorouter had a detailed view of the macro, it could route to any point inside. If magic had a different abstract view for some reason, then those routes could end up colliding with obstruction.

This is what I added to the openlane1 config.json, maybe I'm supposed to include the macro some other way ?

"EXTRA_LEFS": [
		"ref::$PDKPATH/libs.ref/gf180mcu_fd_ip_sram/lef/gf180mcu_fd_ip_sram__sram512x8m8wm1.lef"
	],
	"EXTRA_GDS_FILES": [
		"ref::$PDKPATH/libs.ref/gf180mcu_fd_ip_sram/gds/gf180mcu_fd_ip_sram__sram512x8m8wm1.gds" 
	],
	"EXTRA_LIBS": [
		"ref::$PDKPATH/libs.ref/gf180mcu_fd_ip_sram/liberty/gf180mcu_fd_ip_sram__sram512x8m8wm1__tt_025C_3v30.lib"
	],

Looks good to me. There may be some unneeded obstruction layers in the gds that causes the warning when reading into magic. If it passes precheck, I think you’re fine.

I have noticed before that the GF LEF files for the SRAM macro use obstruction layers on Via1 and Via2 covering the whole cell which might be the source of the problem, but for the most part, the pins all seem to be on the proper layers. @tnt: Would you happen to have a screenshot of the layout around some area where the routing is apparently colliding with the Via2 obstruction layer in the abstract view?

@Tim Edwards

@Matthew Guthaus is obs for vias needed?

I don't think we've used them for the via layers in the past.

I have run into an issue in the magic techfile where I can declare a LEF layer to be an obstruction, or to be ignored, but not both at the same time. If I use the same method that I used with sky130, it seems to produce something usable. Is the

Illegal overlap

message a fatal error or just an annoyance?

The error is fatal and stops the flow there. It produced a GDS already but it doesn't run the rest of the checks ( so LVS / DRC / ARC are not run ).

huh. @Matthew Guthaus Sorry, this wasn’t openRAM.

@Mitch Bailey: It's not OpenRAM, but the issue with obstruction on via layers is generally applicable for any abstract view in any process.

@Tim Edwards Tried it, didn't seem like it changed anything.