Im getting an issue in magic where loading the gds file for a diffusion contact seems to alter the size of the contact leading to DRC issues. The first image shows the gds in klayout where the contact layer is 0.22x0.22. The second image shows in magic where it is 0.23x0.23.

@sage walker Welcome to the world of magic where what you see is not what you get when it comes to contacts/vias. The actual contacts that magic creates in gds are calculated based on design rules in the tech file. In magic, you can draw one large contact region and when you export the gds, the actual mask contacts will be automatically created with the correct size and metal enclosures! Conversely, when reading gds, magic will automatically adjust the size of its idea of the contact layer so that it will (should) produce the same contacts on gds out. This can be somewhat confusing to people experienced with gds editors. You can see the actual contacts/vias that magic will produce with the

cif see <layer>

command ( I think

cif see

by itself will give you a list of valid layers.) Use

feedback clear

to remove the markers.

Is there a way to run DRC so that it checks the dimensions of those "correct" layers rather than on what magic generates? I am using a magic script to check DRC and would like to keep it that way rather than switching the whole thing over to klayout

drc shouldn’t be a problem. The rules for klayout and magic are adjusted for their respective representations.

I have the same issues with MiM capacitors. The contacts are ok with .mag files, buf if I export them to .gds, the conversion creates DRC errors.

@Luis Henrique Rodovalho Thanks for the feed back. Might be a rule problem. What version of the pdk are you using? @Amro Tork @Tim Edwards This is for the gf180mcu process. Do you have time to check the magic/klayout rule correspondence for contacts/vias?

@sage walker I'm not sure how klayout is altering the size of via. GDS files store the locations of polygons. I shouldn't change anything. It would be advisable to send the original GDS file here for me to investigate.

@Amro Tork I think they’re saying that magic is altering the contact/via size. Do you deal with magic rules or just klayout?

@Mitch Bailey Here is my design. Magic has no problems with the MiM contacts for .mag files. Only the .gds has them. Tech file version 1.0.322-0-gcc0029b

@Mitch Bailey Only Klayout. @Tim Edwards could take a look at Magic stuff.

@Mitch Bailey The current issue is with the active overlap of an active contact. The contact size in the gds is .22um which gives the correct 0.065um of enclosure to the left and right side of the contact. When the gds is read into magic the contact is .23 which leaves only 0.06um of enclosure. Here is the gds, im using 1.0.395-0-g815863e of gf180mcuA and magic version 8.3.363

@sage walker (and @Mitch Bailey, @Luis Henrique Rodovalho, and @Amro Tork): One clear issue here is that I cannot find any DRC rules in the open source documentation of the GF180MCU process on https://gf180mcu-pdk.readthedocs.io/en/latest/physical_verification/design_man.html. If anyone knows where to find them, then let me know. If they don't exist, then that's a huge oversight by Google. The original answer by Mitch to the original question by Sage is correct---Magic includes the mandatory 0.005um metal1 overlap of contact in the derived contact layer, so it indicates that a contact area has a minimum size of 0.23um instead of an exact size of 0.22um. For the follow-up question about

sram_contact.gds

, though, the answer is that rule

CO.4

states that diffusion must overlap contact by 0.07um. In magic, the corresponding (modified) rule says that diffusion must overlap the (magic derived layer) contact by 0.065um. Magic's rule is correct and the GDS violates the GF DRC rule. It's possible/likely that this contact layout was never meant to be used standalone, but if the expectation was that the layout should satisfy the layer overlap requirements, then the diffusion should surround the contact on all sides by 0.07um. FYI, you can view exact GDS layers in magic either by viewing them individually in a magic layout using, e.g., `cif see CONT`; or else by running magic with, e.g.,

-T /usr/share/pdk/gf180mcuD/libs.tech/magic/gf180mcuD-GDS.tech

, which displays all GDS layers (or at least all of them that are defined in the tech file) exactly.

@Tim Edwards, thank you. I've updated both magic and open_pdks and there are no problems with MiM contact DRC rules anymore after reimporting the .gds.

Just note that there are no particular guarantees of using magic with GF180MCU for analog work because none of that was in place in time for the first MPW, and we have not scheduled a second MPW. I will fix anything that is pointed out to me as being wrong, as I get the chance to, but there's no budget for it.

@Tim Edwards ah well I feel silly, I am generating these layouts with openram and set the DRC rule configuration as stated in magic rather than reading the actual docs. I did find it quite hard to find actual rules in the documentation as well, but using the built-in search and looking up specific rule names ie. CO.4 got me to specific pages. https://gf180mcu-pdk.readthedocs.io/en/latest/physical_verification/design_manual/drm_07_13.html#contact

Ah, so the rules are there in the online documentation. They really need an index or something. The readthedocs format is really awkward to navigate. (Also I'm surprised you got there from the search engine, because it's pretty bad, too.) But thanks for the tip!

I am having equally many issues on firefox

Okay, so I guess it's just readthedocs' problem.