Hello @Tim Edwards @Mitch Bailey !! I had raised an issue on magic'cs github. Here's the link to the issue : https://github.com/RTimothyEdwards/magic/issues/200. The issue was that magic flags drc errors which are not seen klayout. How can this issue be resolved?

It’s my understanding that the klayout rules are the required rules, while the magic rules include recommendations. Magic also handles implants differently. To see magic’s implants layer use

cif see <layer>

and

feedback clear

to erase.

One of the reasons we run the manufacturing rule checks in klayout is that magic will tend to want to run DRC with respect to a layout that it thinks was generated with magic and therefore followed all of its various layer-combination rules. So it does have the tendency to flag errors that may not exist if the layout was created with a tool other than magic. I have not had the time to look at this example in detail, but I suspect that's what's going on.

Thanks! @Mitch Bailey @Tim Edwards for your inputs. I tried using sky130-GDS.tech instead of sky130.tech while running rcfile sky130A.magicrc and the diff errors are now gone. Attaching the updated drc report. now the only error that pops up is Can't overlap those layers .

@Pranav Lulu I don’t think you want to be using

sky130-GDS.tech

because it’s a very limited set of rules related to GDS only layers. The errors you’re seeing are caused by a hierarchy structure incompatible with magic. (for example, overlapping poly, diff and implants have to be at the same hierarchy level). You can use the

gds flatglob *$$*

command before reading the gds in magic. DRC after this is clean. You could also flatten the

*$$*

cells in the layout to give the same result.

@Mitch Bailey Thanks! By using

gds flatglob *$$*

the errors are almost gone. Here's the corrected drc report.

I was thinking that was this rule (first picture) here (second picture). However, these are connected to the same net, so it might be a waivable error.

@Mitch Bailey Got it. I ran drc on a design using

gds flatglob *$$*

I am getting the Can't Overlap error there as well. I also observed that the errors are caused where there are met1-met4 connections. Here's the final drc report for the design and it's gds.

I assume it’s the same principle. Maybe try this too

gds flatglob *CDNS*
gds flatglob VIA*

Yes. Using above commands removes most of errors.Now the error can be seen only near 2 cap connection where met4-met5 is connected. But I think using

gds flatglob *CDNS*

should have removed them. Here's the drc report

Excellent. As stated before, the above error is for shapes on different nets. In your design, I think they are on the same net, so I think you can ignore it. @Tim Edwards?

@Mitch Bailey: Yes. Magic doesn't have the ability to do a same-net vs. different-net spacing rule, so the most conservative rule is used.

Thanks!! @Mitch Bailey @Tim Edwards

Don’t have much experience with extraction for simulation. I think you need to flatten the design and do

extresist

etc.

Depends on what level of accuracy you want in the simulation. You do need to give some commands to set up `ext2spice`; usually I do

ext2spice lvs

to set "sane" options and then adjust the options I want, e.g.,

ext2spice cthresh 0

to extract all parasitic capacitances. For full R-C extraction, you want to flatten the design into a new cell and extract from that using

extresist

.

@mehdi Tagging you here

I haven’t done much with PEX. I’ll let @Tim Edwards respond.

@Pranav Lulu please do but look at the PMU extraction flow. I think @Jianwei Jia fixed this issue.

@mehdi Yes I will take a look at it.

Sorry, I didn't see this thread earlier in spite of being pinged. I'm looking at it now. There is an issue with the transistors in the macro in the middle that probably requires doing

flatglob *$$*

before reading in the GDS. I have not yet determined if that is what causes magic to hang in the middle of full R-C extraction, but I doubt it (likely, though, it will produce an incorrect netlist). Note, however, that this is a huge layout containing both digital and analog parts. Full R-C extraction is a brute-force method, and is generally not applied to a massive layout like this. I doubt magic is "hanging" so much as just taking days to do the full R-C extraction. It is likely that it stopped displaying output when it hit one of the power supplies. The usual way to handle this kind of a circuit is to cleanly separate the digital and analog parts, run full R-C extraction only on the analog part, and convert the digital part to xspice format. It is doubtful that you would ever be able to simulate the full R-C extracted layout in any reasonable time, assuming that you waited long enough for it to finish the extraction.

@Tim Edwards I tried to do extraction with less digital cells and it completes. I guess magic was not hanged but was working with the earlier big design 😅