============================================================== Guild: wafer.space Community Channel: Information / questions / Pre check magic DRC errors After: 11/30/2025 23:59 Before: 01/01/2026 00:00 ============================================================== [12/09/2025 21:10] buck_042 Hi, we have run the pre -check https://github.com/wafer-space/gf180mcu-precheck for our filled gds. We don't have any DRC error in Klayout, but we have two types of Magic DRC errors. May I ask are those waviable? The MAGIC DRC errors are: **This layer can't abut or partially overlap between subcells** and **p-ohmic spacing to NMOS gate < 0.33um (PP.4b + NP.4c)** Any help will be appreciated, thanks! {Attachments} 2025-12_media/image-35EDA.png 2025-12_media/image-88398.png {Embed} https://github.com/wafer-space/gf180mcu-precheck GitHub - wafer-space/gf180mcu-precheck: Precheck for wafer.space MP... Precheck for wafer.space MPW runs using the gf180mcu PDK - GitHub - wafer-space/gf180mcu-precheck: Precheck for wafer.space MPW runs using the gf180mcu PDK 2025-12_media/gf180mcu-precheck-04ACA [12/10/2025 02:00] mithro_ @Tim Edwards / @Leo Moser (mole99) - Any idea? [12/10/2025 02:15] rtimothyedwards_19428 Not without a screenshot of the layout at the error coordinate. [12/10/2025 02:18] rtimothyedwards_19428 Many errors produced by magic are not really errors. @Tim 'mithro' Ansell : Is there any reason that you are running magic DRC checks? If there aren't any errors that are not being checked by klayout, then I would think you would do best just to go with the klayout checks. A number of magic checks are very specific to magic-produced layout (and therefore are often wrong or confusing when applied to layout that was not generated by magic). [12/10/2025 02:19] mithro_ @Tim Edwards - I believe it is due to the current level of confidence in KLayout DRC deck being lower than we would like. [12/10/2025 02:21] rtimothyedwards_19428 I would tend to suggest doing what Efabless did and using the Magic checks as "backup", something to check for possible errors missed by klayout, but not as a cause for submission failure. [12/10/2025 02:44] rtimothyedwards_19428 `This layer can't abut or partially overlap between subcells` is usually a contact area, and very easy to have happen to layouts not created with magic that are read into magic. The `p-ohmic spacing` error involves layers that magic generates automatically on output, so it doesn't see the actual layers (PPLUS and NPLUS) but infers an error from a combination of two rules and a measurement from COMP (p-tap) to COMP (nFET gate). That one seems more like an actual error but with two layers which magic doesn't even see being involved, it could easily be a false positive. [12/10/2025 02:59] buck_042 Thank you for all your reply, this is helpful! We will use virtuoso to help to debug [12/10/2025 03:02] mithro_ @Buck - I think virtuoso isn't really going to help you here? [12/10/2025 03:06] buck_042 I don't know. Should be not? We haven't tried, should/could we try? I guess the proprietary pdk and opensource pdk share the same layer map, so the gds can easily streamed into virtuoso. [12/10/2025 03:06] mithro_ s/commercial PDK/proprietary PDK/ -- I don't have a virtuoso license so can't tell you anything about if that will work or not. [12/10/2025 03:11] buck_042 Thank you! I have replaced the inappropriate word. [12/10/2025 12:31] mithro_ @Leo Moser (mole99) - Thoughts? [12/10/2025 12:48] mole99 I can set `ERROR_ON_MAGIC_DRC: False` for the precheck and the template. This way we run Magic DRC but do not end the flow with an exception. We already have some false-positive CO errors in magic because some designs use the 9T stdcell library. So this might be the way forward? [12/10/2025 12:50] mithro_ I'm generally of the opinion that things should be `-Werror`, I dislike it when things warn -- either it should be important enough I care about and thus an error or it isn't important and thus shouldn't be produced. [12/10/2025 12:51] 246tnt Although I tend to agree that having both DRC is good, the reality is that the magic tech file is definitely a bit rough on the edges ATM. [12/10/2025 12:55] mole99 Yes, and because of the way magic works, as Tim mentioned, false positives can easily show up (if you don't flatten the complete design, which I would not recommend). [12/10/2025 13:13] rtimothyedwards_19428 It's not so much that it's "rough around the edges at the moment" than that it's _always_ going to be rough around the edges because it works on a completely different database format than other tools, and things just don't match up 1:1 unless you force them to. The choices then come down to (1) modify all library cells so that they do not show errors in magic. I do this from time to time when the solution is innocuous enough---Such as the 9T standard cells Leo mentioned; there's a false positive error flagged where moving one poly edge down by 5nm would prevent the error from showing, but it's one of those types of errors that is impossible to not show a false positive without completely overhauling the way magic handles the technology, which brings me to solution (2) which is to develop a magic technology file that is more 1:1 with the GDS. It is possible to do this but obviously significant development work on a new technology file is required. [12/10/2025 13:19] rtimothyedwards_19428 In the end, I think that defeats the purpose of magic. If you want magic to work and act like all the other layout tools, then you don't need magic, you just need to use the other layout tools. Magic does certain things well; I cannot see squat in virtuoso or klayout or any of the others---everything is a huge cluttered mess. Magic presents layout simply and cleanly, and it is (mostly) obvious where everything is and what all the circuits are doing. It is easy to find connectivity and see DRC errors as they are made. But trying to pretend that it is going to work cleanly with layout made with other tools is a fool's errand. I've written in a bunch of hacks that make it possible to deal with other tools' layouts but for the most part they are hacks and are never going to be anything but hacks. {Reactions} 👍 [12/10/2025 15:55] buck_042 Yes we use some 9t tie high and tie low cells to configure the io cells. We will try use 7t to see what will happen. [12/10/2025 16:01] mole99 Well, it's not a real error. The contact violations (CO) are false positives because magic checks the layout slightly differently. Have you checked where the errors you mentioned above are located in your layout? You can load the markers in KLayout to see where they are. [12/10/2025 17:42] buck_042 Sorry I don't know how to create the maker in klayout, but I have zoomed into the area to see the drc, it shows nothing? {Attachments} 2025-12_media/image-D051A.png 2025-12_media/5ac260151b3aa006106e0da98356f1d2-C21FC.png 2025-12_media/image-6F524.png [12/11/2025 00:39] rtimothyedwards_19428 @Buck : The "layer can't abut" error is clearly a contact thing; possibly you have two contact cuts overlapping in different cells, which only works in magic if the contacts are isolated (i.e., exact overlap of both contact regions). It looks like here that a contact below gets merged by magic into a "contact area" and then the two cuts can no longer be assured of being exactly overlapping (because magic will rewrite the cuts itself using its own algorithm). The only way to avoid having magic complain about it is not to overlap contact cuts in different cells. I can't tell much about the NPLUS/PPLUS spacing error from the screenshot; I'd need a cleaner picture of just COMP, POLY, NPLUS, and PPLUS. The fact that magic's error box is only 5nm high means that it measured the distance from gate to tap as 0.325um, or just barely too short. It could even be the same type of error that Leo was referring to, where because magic is measuring from edges of layers that are not the layers directly involved in the rule, if it's a diagonal measurement, it could differ by just enough to be a nanometer or two short of the rule. [12/11/2025 00:49] buck_042 Hi Tim, thank! For "layrt can't abut" seems like a false positive error? Because I just measre the size of the contact, whcih is exactly 0.22um * 0.22um (the contacts are exactly overlapping). For the second drc error, this is what only shows the poly and N/PPLUS area, [12/11/2025 00:50] buck_042 {Attachments} 2025-12_media/image-22F85.png [12/11/2025 00:51] rtimothyedwards_19428 @Buck : It's a magic thing. . . Contacts are drawn as "contact areas" (much like "VIA" statements in LEF or DEF) and magic automatically generates the cuts. That makes the layout simpler and cleaner, and easier for magic to do extraction, DRC, etc. The drawback is that it puts additional restrictions on the placement of contacts that don't exist for other tools. {Reactions} 👍 ❤️ [12/11/2025 00:57] ruichenq @Tim Edwards Can we ignore these DRC violations reported by Magic? Since KLayout shows a clean DRC report, how can we determine whether the design has actually passed the pre-check? [12/11/2025 00:59] rtimothyedwards_19428 I would trust klayout. I'm trying to determine if the PPLUS/NPLUS spacing error is real or not, but as usual the problem is trying to understand the garbled mess that is the rule documentation. In all likelihood I implemented the spacing rule as I understood it, which may or may not be how it is actually implemented by GF. {Reactions} 👍 [12/11/2025 01:02] ruichenq I see. Thanks for your help! We will use the KLayout report in the precheck as the sign-off DRC for this tapeout. [12/11/2025 01:13] rtimothyedwards_19428 Actually after re-reading the NP and PP rules again, I'm pretty sure the rule in magic is just bogus. I think in one place I misinterpreted a spacing to NCOMP as a spacing to NPLUS; consequently the rule is flagging an error at a distance of less than 0.33um when the actual minimum distance appears to be 0.32um. The fact that it is off by only 10nm is why it hasn't come up before. [12/11/2025 10:33] mole99 Hi @Buck if you open the layout in KLayout, you can load markers using Tools -> Marker Browser. [12/11/2025 10:34] mole99 {Attachments} 2025-12_media/Bildschirmfoto_vom_2025-12-11_11-31-41-F50FC.png 2025-12_media/Bildschirmfoto_vom_2025-12-11_11-32-47-D8E44.png [12/11/2025 10:35] mole99 You can find the marker files in `run//11-magic-drc/reports/*.lyrdb` or `run//13-klayout-drc/reports/*.lyrdb`. {Reactions} ❤️ 👍 (2) ============================================================== Exported 33 message(s) ==============================================================