DRC errors on analog pad provided as part of the SKY130 pdk

[simonwaid]

The analog pad (as well as other pads) provided as part of the skywater 130 pdk contains DRC errors

Steps to repoduce:

• Install magic rev. 8.3.399
• Install the skywater pdk using open_pdks rev. 1.0.414 to the default location
• Copy /usr/local/share/pdk/sky130A/libs.tech/magic/sky130A.magicrc to your working directors and rename it to .magicrc
• Open the analog pad using magic magic /usr/local/share/pdk/sky130A/libs.ref/sky130_fd_io/mag/sky130_ef_io__analog_pad.mag
• Create a Box around the pad, press "a" followed by "x" to expand everything.
• Drc -> DRC Complete
• Drc -> DRC Update
• Options -> DRC Manager shows "mcon spacing <0.19um" and "Metal5 overlap of via4"

Similar issues are present also in other pads, such as sky130_ef_io__vccd_lvc_clamped3_pad.mag

[RTimothyEdwards]

@simonwaid : I'm aware of these errors, or at least the metal5 overlap of via4 error. The overlap errors occur near 45 degree angle edges of metal5 in the layout, and as far as I can see from the layout, these actually are real errors, in that the corner of the via is too close to the edge of metal5 by a euclidean distance measure. Magic flags this. Apparently calibre doesn't, since these pads pass calibre rule decks with no issues. I'm not sure how to approach the issue other than redrawing all of the pads so that all tools agree that there are no errors.

[simonwaid]

I've tried to modify the files from which the DRC errors were stemming. Replacing sky130_fd_io_pad_esd and sky130_ef_io_esd_pdiode_11v0_array with the modified ones (io_mod.zip) solves the issues for sky130_ef_io__analog_pad.mag

The files sky130_ef_io__vccd_lvc_clamped3_pad.mag and sky130_ef_io__vssd_lvc_clamped3_pad.mag also contain DRC errors. I've tried to edit them in an attempt to solve the issues. I can get rid of the error "Can't overlap those layers". Even though the resulting layout is ugly. However, the error "Spacing of metal2 features attached to and within 0.28 of large metal2" remains. This looks like a magic bug to me, as there are no features in metal2 around the location of the DRC error.

Could you please check if the modified files are good and ideally include the new files into the pdk?

[RTimothyEdwards]

Sure, I'll take a look. I will probably be another week before I can do anything about it, though. There are definitely errors in magic resulting from the way the files are read in from GDS. It has been my intention to provide DRC clean layouts in magic, so you're doing what I intended but haven't had time to work on.

[simonwaid]

Thank you! I'd need DRC clean pads for a tape out in mid June. But I understand that you're extremely busy. Please let me know if I can do anything to make your work easier.

[RTimothyEdwards]

@simonwaid : I just want to make it clear that these cells should cause no issues with tapeout. There are two separate issues here that are illustrated by the m5 overlap error and the mcon spacing error on the analog pad. (1) All library cells have a .mag file that is effectively an "abstract" view. These views look like .mag layout but they have a "GDS_FILE" property in them that points to a GDS file with the cell contents. The GDS file is the "golden reference" and is the data that gets output when you do "gds write". The magic layout view, ideally, is the same as the GDS and you can go from .mag to GDS and back without changing anything. But that's not always the case. In the case of the analog pad, I checked the GDS data and it is correct and has no GDS errors. So the issue arises from reading the GDS back into magic when creating the library, which is creating an artifact that shows up as a contact spacing error. (2) The metal 5 overlap is an issue where magic's DRC and Calibre's DRC disagree on the definition of overlap of a contact when the metal edge is at 45 degrees. Since this problem is DRC clean according to Calibre, then it will be DRC clean for SkyWater's DRC run and will not cause the design to be rejected. While I disagree with Calibre's implementation in this case, the geometry in question has been included in millions of production chips so obviously is not a problem in practice.

So, in short, the main issue that you will have with these cells is that the DRC errors showing in magic will tend to prevent you from seeing and finding other errors in the layout which may be real. That's why it's helpful to have magic showing these cells as DRC clean. But if you can work around that issue, then there won't be a problem with tape-out.