Hi all, on my tapeout job, I am failing for Field Oxide Metal (FOM) Density:

STDOUT: {{Step Update}} Executing Check 6 of 6: Klayout Field Oxide Mask Density on [caravel_2311ea22.oas]
STDERR: [ WARN ] FOM Density Check Result: 'caravel_2311ea22.oas' has 147 DRC violations.

It looks like we are under density for our FOM in all cases, if I am reading the log correctly"

fom density below 0.33 : 1713/2730 is 0.3268 for tile ((1820,1610;2520,2310)), area = 490000

I saw this thread where @jeffdi explained "_typically issues with being under on Li are due to using too many or all fill cells in a design vs decap. too high Li is usually due to using decap only. One solution is to use the modified EF decap size 12 cell which has a balanced Li and diffusion. This will address issues with Li density as well as FOM density (tap+diffusion)."_ In that discussion, he suggested adding the following to the

config.tcl

file:

set ::env(DECAP_CELL) "\
	sky130_fd_sc_hd__decap_3 \
	sky130_fd_sc_hd__decap_4 \
	sky130_fd_sc_hd__decap_6 \
	sky130_fd_sc_hd__decap_8 \
	sky130_ef_sc_hd__decap_12"

I'm looking to do the equivalent in my

config.json

file, but I have 2 questions: 1. Since my density is consistently under, not under/over as in the example discussion, is this decap cell still a good choice for my problem? 2. I do not see the

DECAP_CELL

config documented for the

config.json

, is how can I adjust this (or FOM in any way) with the current Openlane Flow?

@Peter Herrmann don’t know if there’s much you can do on your side. @Tim Edwards this design has 12 2kbyte dual port srams. All the fom density errors are around the srams. The fill around the sense-amps appears less than expected, but it may have to do with the low density of diffusion in the sram memory cells. They have dense poly, so not possible to add diffusion fill. Maybe this one should be waived?

Dang alright. For what it's worth, I added

"DECAP_CELL": "sky130_fd_sc_hd__decap_3 sky130_fd_sc_hd__decap_4 sky130_fd_sc_hd__decap_6 sky130_fd_sc_hd__decap_8 sky130_ef_sc_hd__decap_12",

to

config.json

and it had no effect on the outcome (still 147 FOM density errors, in the same spots around the SRAMs)

Are these the SRAMs from the PDK? I thought they had tap layer shapes placed all around the SRAM core so that the 100% density in that area would offset the low density inside the core. If not, then it's probably a good idea to add it. I'm pretty sure that technique works until you get to the 8kb SRAMs.

@Tim Edwards yes these are the

sky130_sram_2kbyte_1rw1r_32x512_8

from the latest recommended version of the PDK.

You'll need to add large blocks of tap diffusion the open areas inside the SRAM macro to get the density of the diffusion layer high enough for the whole block to pass. Apparently that has not been done in the cell that is in the SRAM macro library.

@jeffdi Since the density is just over the under the limit, is this something that can be waived?

It has been waived in the past, but it's really up to SkyWater as to whether they will allow it or give us push-back. If it's possible to make the layout clean with respect to the density rules, that's preferable. It is, of course, their own cell that is failing density, and the only reason that it fails density is because they moved the density targets. But we don't have the expertise to re-make the SRAM cells with a larger diffusion area per cell.

@Tim Edwards I don't know where in the flow I can make the change you suggested; would I be editing the

sky130_sram_2kbyte_1rw1r_32x512_8.mag

and manually adding tap diffusion cells? I'm exploring strategies (increasing spacing between the SRAMs to more than 700um so that no step check has 2 SRAM cells, not using macros for memory) but no success.

Don't edit the

sky130_sram_2kbyte_1rw1r_32x512_8.mag

cell itself because it is effectively an abstract view pointing to a GDS file that contains the actual contents; anything that you do to the

.mag

layout will never appear in the output. Adding the tap diffusion to the cell above

sky130_sram_2kbyte_1rw1r_32x512_8

(which is presumably the user project wrapper?) is probably the best way.

We will try to waive with the foundry. Is this the last issue you have?

@jeffdi Yes, other than this our builds are clean

Ok. Great.

Sounds good. Thanks everyone!