<@U017UPJEGKZ> i have the same DRC check error for...
# magic
m
@User i have the same DRC check error for my design. I layout my analog circuit and i need a sealring for this design. But, when i use sealring that generate by magic, it have a DRC error like that: "Deep N-well spacing to N-well < 4.5um (nwell.7)". I think, in my layout, the Nwell is on the Deep N well, that is no DRC error for the example. So i don't know how to solve this problem. And how can i verify exactly my layout before pass Efablesss ( or Skywater) check. This problem is critical or not? Thank you, and have a nice day ! 🙂
w
The deep N-well spacing to N-well is for unrelated (unconnected) nwells
I am a bit confused, your design appears to have a DRC error you are trying to clear?
Your color scheme seems a bit different than mine, but it seems you might have the wrong well placement? The deep nwell layer should only be under drawn nwell / pwell layers and the nwell has to extend 0.4um past the end of the deep nwell on all sides (and no pwell can be within 1um or something of the end of the deep nwell)
m
that's right, I drawn a ring of Nwell and extend 0.4um. But i think i have some problem with Nwell of some Pfets in the Well ring.
Did you use Deep N well and sealring for your design and it pass DRC check?
w
I have a design that uses a deep nwell that passes magic DRC. I have not submitted anything through the efabless platform yet though, which is a second round DR
I think the issue you are getting is that your individual nwells over the deep nwell are less than 4.5um apart
t
@Manh Tran: There is some artifact being produced. I can reproduce the problem here. I'll investigate and generate a fix. It does not appear to be a real error.
m
Thank you @Tim Edwards and @Weston Braun very much! So how i know that my design will pass efabless (or skywater) DRC check before submit? What another tool i can run to verify this DRC error?
t
@Manh Tran: I will have the tech file fixed shortly; I'm a little delayed due to a couple of meetings (like sitting in on Weston Braun's presentation. . . ).
m
Oh. that is nice. Thank you very much and have a nice day!
t
I just fixed this. . . it was an incorrect rule implementation in magic where the "spacing" rule for spacing between a->b usually gets implemented in both directions (a->b and b->a). However, the "surround-ok" rule type (e.g., distance from nwell to dnwell is 4.5um except where dnwell is already surrounding nwell) is not symmetric like this, and magic wasn't prohibiting the swapped case, which then produces really weird results. But I also found that the magic tech file in open_pdks had the types for the surround-ok spacing rule in the wrong order for a couple of the rules, so I had to fix that, too. Bottom line is that this is now fixed if you update both magic and open_pdks (open_pdks you don't need to reinstall everything; just cd to the sky130 directory and run "make tools-a ; make install").