Hi Mattthew, we encountered some FOM density errors if the channel between the SRAM macros is small (less than 150um?). The reason (I guess) is the empty space around the memory array (will be double between two macros). So, is it possible to add sky130_ef_hd__filler/decapx cells to fix it? The only option now is making the channel bigger to pass the FOM, but it costs much more area. Btw, have you got any updates for the 4KB/8KB/16KB macros? Have those been tested? Thanks

We still haven't received our design so nothing more has been tested... I haven't placed the memories so close so I'm not sure. You could add metal...

Thanks for the info. I think FOM density is related to diffusion layer, filling the empty space with ef_decap/filler cells would help? @jeffdi @Tim Edwards do you have any suggestions? Thanks

What size memory were you using? Do you have an example floorplan?

I am using 1/2kbyte cells. You can see the macro placement here https://github.com/Nguyen-C-Dao/caravel_rocket_alpha/blob/main/openlane/user_project_wrapper1/macro.cfg (see the picture in the main page).

Hrm. We had a similar number of memories but didn't have that issue.

Did you run tapeout job/check with recent versions (e.g., mpw-6c)? I see some others also reported FOM density errors related to the SRAM macros

@Nguyen Dao: This is a fundamental issue that is caused by the density of diffusion inside the (foundry-designed) SRAM core cell. The SRAM core cell was designed to meet a specific FOM density requirement. Then SkyWater upped the density requirement to give themselves a bit more margin, and the SRAM core now falls below that new density requirement. I had Matt put tap diffusion all around the outside of the SRAM cell to make up for the lack of density in the core. But if you get several SRAM blocks close to each other, it can still fail density in some 700um x 700um stepped check areas. On the other hand, when that happens, the design usually fails density by one or two percent, and we can get SkyWater to waive the error (partly on the reasonable grounds that it's their fault to begin with).

Thanks @Tim Edwards, we changed the floorplan and passed the check. The failed one was just about 1% less than the required number (33%). Do you think it is better to add few more decap/filler/tap cells insides the macro to pass the check (regardless the channel width between the SRAM blocks)?

@NguyenDao We did run it and had other incorrect DRC errors. @Tim Edwards I think that we only did that for the 8k SRAM. The others didn't need it...

Ah, then doing it for the others might solve the low FOM density problem with having multiple SRAM blocks close to each other.

@Matthew Guthaus is the 8K SRAM available for the next run?

@NguyenDao we haven't tested it