4. Is there anything special we need to do to rebuild your MPW2 application? Is the maglef cell replacement that solves DRC all part of the configuration? Where is that handled?

I'm not sure how OpenLane handles this still, so you would need to ask them...

so your final run to generate gds was not drc clean?

It was clean if I read in the GDS and replaced the memories with the LEF files

ok thanks

@Matt Venn: The issue is that we are currently abstracting the SRAM modules during DRC checks, but that abstraction is done on the whole module, so we have a script that checks modules by name and abstracts the ones that match the four blocks in the SRAM module library. Matt's test chip was all new blocks with all new names, so they don't get abstracted by the system. If you use any "known good and validated" pre-built SRAM macros, they should pass DRC checks on the system. If I can get around to finishing adding the base cell layouts to the installed PDK, then I can get the system to abstract just the base cells, which would then automatically make any block compiled from OpenRAM potentially usable without generating false DRC errors.

@Tim Edwards, Are we allowed to use SRAM Hardmacro generated inside the PDK in MPW-3 shuttle ? DRC issue will be resolved in Magic DRC flow ?

@Dinesh A: The prechecker detects SRAM macros from the

sky130_sram_macros

library and abstracts them automatically when running DRC so they will not raise lots of errors. At some point we will get this working for any SRAM block created with OpenRAM or otherwise using the SkyWater base SRAM cells.

@Tim Edwards, Thanks, this will help, I see sram ram macro detection logic inside ./checks/drc_checks/magic/magic_gds_drc_check.py.