Precheck crash with SRAM DRC

[mguthaus]

Magic DRC crashes during pre-check by eFabless on our design when using the mpw-8c tag.

The final log message is:

[12/30/22 03:26:24 PST] STEP UPDATE Executing Check 8 of 14: Magic DRC [12/30/22 04:28:04 PST] EXCEPTION Script error code: -9

We are are using this project/commit with 10 SRAM designs: https://github.com/VLSIDA/openram_testchip2/commit/6e832a85b7322f81ad115c4057c8acdd4317ce9c

Is there a recommended methodology to deal with core memory design rules and pre-check?

[RTimothyEdwards]

The way we handle SRAM design with magic DRC is to pre-load the known SRAM designs using the abstract views (which are DRC clean) and then loading the design from GDS using the "-noduplicates" option so that the SRAM cells remain abstracted. This method should work for the array core cells as well, but it would require that the SRAM macro library have abstract views for the core cells. I can work on trying to get this implemented.

[RTimothyEdwards]

@mguthaus : I looked at the precheck implementation; basically it will preload anything that has "sram" in the name and which exists as an abstract view in the "sky130_sram_macros" library. I can probably get this to work simply by getting open_pdks to generate abstract views of the SRAM core cells. Which core cells are you using in these designs?

[mguthaus]

Perhaps we should specify a separate list of core memory macros in the design? We have some macros that are not available in that library and presumably other users will generate custom macros that are not part of that library.

When we do DRC in OpenRAM, our Makefile copies over the abstract cell views (.maglef -- a magic file with abstract views) that we use from the "sky130_fd_bd_sram" (or our copy is https://github.com/VLSIDA/sky130_fd_bd_sram/tree/main/cells ) cell repo: MAGLEF_SUFFIX := maglef MAGLEF_FILES := $(sort $(wildcard $(SRAM_LIB_DIR)/cells//*.$(MAGLEF_SUFFIX)))

Designs should pass DRC in Magic using those.

[RTimothyEdwards]

Technically, you should not be violating normal DRC rules and only approved SkyWater cells can violate those specific rules, or else we're going to get kick-back from SkyWater for cells that violate their manufacturing DRC rule set. For any other intentional violation of manufacturing rules, we would have to work out the waivers in advance with SkyWater.

Otherwise, it's most helpful to know that your abstract views come from the sky130_fd_bd_sram repository, because it's relatively easy for me to add that library to open_pdks and also to the precheck cell list (which currently is collecting abstract views by listing the contents of the maglef/ directory in sky130_sram_macros---but that's trivial to extend to add sky130_fd_bd_sram).

Of course, I'd also like to know why magic is crashing. If it's an OOM thing, then I won't be able to do anything about it.

[mguthaus]

Ah, yes, just using the abstract of the library cells is fine as well. We don't do anything beyond that.

It is crashing on eFabless' server, so I can't tell what is happening.

[RTimothyEdwards]

I didn't really expect you to know why magic was crashing. I'm running DRC on the imported GDS of your user project wrapper and seeing if I can duplicate the crash condition. If not, I'm just going to assume it is caused by low memory overhead on the server used for precheck. Meanwhile, I'm testing the integration of sky130_fd_bd_sram into open_pdks, so I should be able to have that all working for you in a day or two once I can get it verified and pushed through to the server.

[RTimothyEdwards]

Just reading in GDS of your project, I got a DRC count of 14,639,402. No crash. Using the LEF views from sky130_fd_bd_sram, I got a DRC count of 6,971,468; I didn't pre-load every cell from the library so it probably could be a bit less. The LEF views in the library are not meaningfully constructed. I think I've mentioned before that abstract views of the base SRAM cells would need to be hand-drawn. Still, halving the DRC count could make the difference between magic crashing and not crashing on the server.

[mguthaus]

I did not create the LEF files and don't know how they were created. We are using the MAGLEF files (extension .maglef). The MAGLEF files should have the back-end layers only, minus LI, possibly.