SRAM Density DRVs in Innovus

[m-usama-z]

Hi. I'm using Innovus for PnR, and precheck for DRC check. I'm having difficulty passing a GDS with SRAM through the "Klayout minimum metal density area clearance" check; It gives 1200 errors, all in SRAM, 200 errors per layer, from li to met5. Can anyone advise what this means? I apologize if it is already somewhere in the internet; in that case, kindly share the link.

Edit: I've placed placement halo, and routing halo for layers li1 to met4, with a space of 2 um around the SRAM instance.

[RTimothyEdwards]

I do know that the rule implementation for density rules in the klayout precheck deck has wild-carded the layer purposes such that almost every purpose other than, I think, metal hole (and recently, metal fill block) is considered metal for the purpose of counting metal for density.

Since I am not aware of the SRAM causing problems like this in the openlane flow, my best guess is that Innovus is putting some layer type over the entire SRAM layout, or a large portion of it, that is getting interpreted by the klayout DRC rule as counting toward total metal area, when it should not be. Quite possibly it's the halo that's doing it. What layer/purpose do you use for the placement halo (assuming it's translated into GDS)?

[m-usama-z]

Placement halo to prevent placement of anything on or around it, and routing halo to prevent routing from li1 to met4. Though, there are a lot of power straps in met5 overlapping with SRAM; is that fine? Kindly also tell if maximum density rules are also getting checked here or not. Thank you so much for your timely response.

[RTimothyEdwards]

Power straps can be a problem for over-density of metal, but it's rare and I'm pretty sure that's not the problem here since you're getting errors reported on every single metal layer.

Note that "minimum metal density clear area" is the same as "maximum metal density". The "clear area" indicates that the mask is inverse, and is a confusing nomenclature that I don't much like. The precheck density check is intended to catch areas of too much metal. The opposite check, for too little metal, is assumed to be taken care of by automatic fill pattern generation. There is a final check for under-density of metal after the fill pattern generation, but it's not part of precheck, and it is a pretty rare case that fails under-density. But if you're already over-density in metal, then adding fill patterns isn't going to make anything better. So that one can be calculated in pre-check.

So my suspicion here is that your placement halos are getting written to GDS as some layer with the same layer as the metal but a different purpose number, and that layer is confusing klayout into believing that the entire SRAM is covered with 100% metal on all layers, resulting in a check failure. I'm trying to find out what that GDS layer:purpose pair number is, because I can then correct the rule to ignore it and not count it as metal area when doing the density check.

[m-usama-z]

Thanks again. I'll try to compare the layer map with the metal layers:purposes in skywater Excel sheet, on my next work day, and shall share what I can. Edit: A slightly irrelevant noobish question: There is an issue at the following link: https://github.com/google/skywater-pdk/issues/308 Can you kindly express your opinion about the edit suggested there? Is it a harmless edit? I'm asking here because there was no response to my comment there.

[m-usama-z]

Sorry, correction of previous comment: Edit: A slightly irrelevant noobish question: There is an issue at the following link: https://github.com/google/skywater-pdk/issues/308 Can you kindly express your opinion about the edit suggested there? Is it a harmless edit? I'm asking here because there was no response to my comment there.

[RTimothyEdwards]

To my knowledge, yes, that makes the tools happy and is a harmless addition (and licon is the correct cut type to put there, regardless). (The open source tools don't care whether or not there's a cut layer there, which seems more proper to me.)

[m-usama-z]

Hammer provided this lefpin map file for sky130: sky130_lefpin_map.txt There are some mismatches between this file and the skywater layer info excel sheet. For example, purpose numbers 41 and 58, are used in this file, but not mentioned in the excel sheet. Could this be causing confusion in DRC? Kindly tell your opinion about another question as well: there are some purpose numbers mentioned in the skywater layer info excel sheet, which were not used in this layer map file, e.g. 13, 10, 60, 0, 14, 25 and 15. They are also not mentioned in a layer map discussed in this issue: https://github.com/google/skywater-pdk/issues/313 Would the absence of these purpose numbers in the map file cause issues in fabrication?

[m-usama-z]

The example for sky130 provided by UCB hammer, when checking DRCs with Calibre, makes SRAMs black boxes. Should SRAMs be a part of density rule calculations or not? P.S.: I don't have Calibre.

[m-usama-z]

Reading the DRC script solved the problem. It expects die area bounding box in layer 235, purpose number 4, which was not in my innovus layer map file. Including the following in the layer map file solved the problem:

DIEAREA ALL 235 4