I'm trying to include a gf180mcu_fd_ip_sram__sram256x8m8wm1 in a design. I've followed the

Openlane_docs/Hierarchical chip design

guide for adding the macro. It's placed and connected upto to the PDN. I can see it in the gds, and it looks correct. But I get an LVS error,

LVS reports:
    net count difference = 35
    device count difference = 0
    unmatched nets = 9
    unmatched devices = 2
    unmatched pins = 0
    property failures = 0

Total errors = 46

It seems like I've got some named nets which don't connect.

Net: _1302_                                |Net: _1302_                                
  gf180mcu_fd_sc_mcu7t5v0__tiel/ZN = 1     |  gf180mcu_fd_sc_mcu7t5v0__tiel/ZN = 1     
  gf180mcu_fd_sc_mcu7t5v0__antenna/I = 1   |  gf180mcu_fd_sc_mcu7t5v0__antenna/I = 1   
                                           |  gf180mcu_fd_ip_sram__sram256x8m8wm1/CEN   

Net: mod.u_cpu.rf_ram.RAM0/CEN             |Net: \mod.u_cpu.rf_ram.i_wdata[1]          
  gf180mcu_fd_ip_sram__sram256x8m8wm1/CEN  |  gf180mcu_fd_sc_mcu7t5v0__buf_1/Z = 1     
                                           |  gf180mcu_fd_ip_sram__sram256x8m8wm1/D[1] 
                                           |  gf180mcu_fd_sc_mcu7t5v0__antenna/I = 1

found https://github.com/efabless/caravel_mgmt_soc_gf180mcu/tree/main/openlane/GF180_RAM_512x32 which interestingly wrap and blackbox the foundry provided macro w/ a separate config.

Unless that's just a convenient way to wrap the 4 SRAM IP blocks together. I'll try it out in my design

I also noticed people guard the power pins too: https://github.com/alokerdas/uP16_gf180/blob/bf3d2fa7f6ea9929843092921ecebbccbe7eaa2c/verilog/rtl/user_project_wrapper.v#L167

The actual mgmt_core_wrapper doesn't seem to use that GF180_RAM_512x32 config as a hardened macro. If you look at it's config.tcl it defines the lef,gds,blackbox for the IP block directly.

ah that's a a good find! are you able to correlate this line to an informative commit / pr message? for some context.

I wrote the hierarchical guide. I dont know why you are getting this error. The guide was written for sky130 and did pass the lvs. Maybe its gf180 related. It needs to be properly debugged and fixed

@proppy: The wrapper was done so that the power supplies could be connected up to m4/m5 to match what the PDN generates. I don't know why it was black-boxed, and I don't think it should be.

@Tim Edwards I'm not actually sure those are blackboxed, it seems that the blackbox is set on the foundry cells and not the wrapper around them.

Yes, I followed that. I have power connected via vias from the PDN. It's still listing 35 nets "spare" in the spice netlist. These are all nets from the SRAM macro, A/D/Q/CLK/WEN signals. Even through

@gregdavill Are you saying that the connections to the SRAM macro appear connected in GDS, but extract as not connected? Is your repo available?

@Mitch Bailey: There are issues with the way the SRAM hierarchy is made which prevents the SRAM from extracting properly. I'm trying to figure out now what set of cells I have to flatten to make it extract correctly (very much like the SkyWater I/O cells).

No pins probably. I’ve seen magic “miss” connections if there’s an extra hierarchy with no pins.

Well, there's definitely one major issue I found which is that a low level cell is missing the P+ implant over some of the area, and somebody "patched it over" by dropping a layer of P+ in the top level cell---implying that the SRAM will never be able to read in correctly unless everything below the top level is flattened. I'm currently trying to figure out if I can repair the P+ in the lower-level cell and get it to read in in a halfway decent hierarchy. I have not found anything that obviously causes an issue with the power supplies, but the extraction clearly merged

vdd

with the substrate, causing a complete mess in the extraction. Once I fix the P+ issue, I'll re-extract and see if that problem still exists or not.

@Mitch Bailey Yes, that appears to be the issue. They look connected in GDS, but not in the extracted. Yes, the repo is here, I'm trying out the 256x8 block. https://github.com/gregdavill/gf180-mpw0-serv

Just adding a quick summary of my experience here: Based on @proppy's suggestions, I tried to make SRAM work inside my GF180 SPELL submission. Couldn't easily get past LVS. Since I only needed 512 bytes and had plenty of die space, I decided trying a DFFRAM implementation instead (https://github.com/wokwi/gf180_spell/blob/b24799a6b766372e925b7a8945b19258f5ff9877/verilog/rtl/rambus/rambus.v#L32-L47). This time, it hardened successfully (but took a very long time):

I don’t think the current implementation of SRAM will pass LVS with magic/netgen. Not that it’s wrong, it’s just that the layout isn’t designed to be extracted in magic (out of hierarchy device layers). The only thing I can think of at the moment is to black box the SRAM.

@Sean Cross fyi