@User I've seen a couple reports of klayout drc errors for VIA4 spacing < 0.8um. Wondering why these aren't flagged in magic. Looking at the magic tech file,

width v4/m4 1180 "via4 width < %d (via4.1 + 2 * via4.4)"
 spacing v4 v4 420 touching_ok "via4 spacing < %d (via4.2 - 2 * via4.4)"
 surround v4/m5 *m5,rm5 120 absence_illegal \
	"Metal5 overlap of via4 < %d (met5.3 - via4.4)"

 exact_overlap v4/m4

it appears that the spacing is set at 0.42um. Is my understanding correct? Is v4 width inside m4 1.18um minimum? I believe the PDK has 0.8um for both width and spacing. https://skywater-pdk.readthedocs.io/en/latest/rules/periphery.html#via4 So if that's the case, I'm wondering why the v4 errors are not being flagged in magic. Does it have something to do with the way magic handles via as an area, rather than individual cuts? Or is it because v4 rules require the METAL5 environment variable definition? How do you ensure that magic is using the METAL5 version of the rules for caravel?

The spacing between via4 areas is set to 0.42um, where every via area has at least 1.9um metal4 and metal5 surrounding all contact cuts (from the cifoutput rule

squares-grid 190 800 800

. So the effective distance is 0.42 + 0.19 + 0.19 = 0.8. So the problem here is that when magic automatically creates layers like implants and contact cuts, it doesn't care what the actual GDS it read in is doing, because it will write out correct GDS according to its own rules. So if you want to use magic to run DRC on some unknown GDS created from another tool, then you really need to create a different tech file for magic that captures implant layers and contact cuts exactly so that it can run a proper DRC check on them. There is such a tech file I wrote for magic, which is sky130A-GDS.tech, although I only added DRC rules for the implant layers (HVI, HVTP, NSDM, etc.) and not for contact cuts. Since there is a klayout DRC deck that works well, however, it seemed like the better solution was just to complete development of the klayout DRC deck and use klayout for complete DRC checks.

@User Now it makes (a little more) sense. Thanks for the explanation. I assume that the openlane routing tools output a DEF file that is read into magic(?) to create the final GDS. Do you have any idea how these via spacing errors might occur? https://skywater-pdk.slack.com/archives/C017HPHCMEY/p1636101232126800?thread_ts=1635955774.115200&amp;cid=C017HPHCMEY

@User: Yes, openlane generates a DEF file that is read into magic. The DEF file would normally define contact arrays in the VIAS section and then use them as part of the SPECIALNETS section for the power routes. Magic normally does not do especially rigorous parsing of the VIAS section entries for the same reason stated above; it will generate contact cuts by its own rules, so it only really cares about the via area and layers used. Stupidly, I wrote the LEF/DEF read routine to parse LEF and DEF directly into magic layers, when I should have run them through the same layer generation recipes used by GDS reads, since LEF and DEF represent mask layer geometry. That little bit of stupidity (which I mean to fix, some day) causes some weird differences between the way mask geometry gets converted into magic layers in LEF and DEF vs. GDS. Either the geometry of your screenshot was caused by such a mismatch, or else the GDS was not generated by reading DEF into magic and writing out GDS. To figure out what is going on in that layout, I'd need to know the exact flow from openlane to layout.

@User Thanks for the explanation. I'll see if I can track down the flow and get back with you.

@User @User Is there a way to set and solve the DRC error as I'm new to this but need to submit my design for mpw-3 shuttle 🙂

@User Sorry, I have no experience in fixing DRC errors for the shuttle runs. Is it possible to move the vias in klayout and GDS out from klayout? If it is, you should be able to replace the

gds/user_project_wrapper.gds

with the modified file and try the precheck again.