wafer.space Community - Pre check magic DRC errors

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!

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

@Tim Edwards / @Leo Moser (mole99) - Any idea?

Not without a screenshot of the layout at the error coordinate.

02:18

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). (edited)

@Tim Edwards - I believe it is due to the current level of confidence in KLayout DRC deck being lower than we would like.

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.

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.

Thank you for all your reply, this is helpful! We will use virtuoso to help to debug

@Buck - I think virtuoso isn't really going to help you here?

Tim 'mithro' Ansell

@Buck - I think virtuoso isn't really going to help you here?

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. (edited)

Buck

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. (edited)

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.

Tim 'mithro' Ansell

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.

Thank you! I have replaced the inappropriate word.

Tim Edwards

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.

@Leo Moser (mole99) - Thoughts?

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?

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.

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.

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).

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.

13:19

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.

1

Leo Moser (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?

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.

Buck

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.

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.

Leo Moser (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.

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?

@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.

Tim Edwards

@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.

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, (edited)

00:50

@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.

1

@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?

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.

1

I see. Thanks for your help! We will use the KLayout report in the precheck as the sign-off DRC for this tapeout.

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.

Buck

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?

Hi @Buck if you open the layout in KLayout, you can load markers using Tools -> Marker Browser.

10:34

10:35

You can find the marker files in run/<timestamp>/11-magic-drc/reports/*.lyrdb or run/<timestamp>/13-klayout-drc/reports/*.lyrdb.

1

2