Hi all, I'm trying to perform DRC over an analog chip design but the

maximal

version gets stuck after checking

M1.c

even when all flags are disabled.

/usr/bin/klayout -c misc/klayoutrc -t -e -b -zz -r /opt/pdks/ihp-sg13g2/libs.tech/klayout/tech/drc/sg13g2_maximal.lydrc \
        -rd in_gds=<GDS>.gds \
        -rd log_file=<LOG>.log \
        -rd report_file=<REPORT>.lyrdb \
        -rd offGrid=false \
        -rd density=false \
        -rd filler=false \
        -rd noRecommendedRules=false \
        -rd sanityRules=false \
        -rd checkDensityRules=false

sg13g2_minimal.lydrc

works fine and the PDK was updated today. • There's any mistake on the drc command? • This may be caused by hardware limitations?

How long did you wait ?

I am currently running the DRC for your layout. It hangs on

M1.c1

for me as well. I'll take a closer look.

DRC was running all night long and it got stuck again after

M2.c

Thanks for the report. Please try the attached DRC script – it fixes the problem with your layout for me.

Thanks a lot for the effort put into this problem I will test it as soon I arrive to the lab

Great to hear!

I'm curious if that helps with my DRC runtime issue 😅 Let's try it.

The density checks are still the same, sorry.

@Andreas Krinke It's not density check in particular, it's the whole DRC in general. I couldn't run it on my projects, ... I think las time I tried I killed it after 17 hours and gave up on it.

We should definitely take a look at that! Is the layout available?

Yes, if you go at https://github.com/TinyTapeout/tinytapeout-ihp-0p2/releases/tag/tapeout you can find either the OAS of in the

ihp_submission.zip

the GDS will be inside.

So you mean

tt_ihp_wrapper.gds

? Yeah, that's quite big. I will give it a try.

Yes that one. It's 18 mm^2 surface.

@Andreas Krinke The script detects a lot of errors that the

main

and

dev

drc scripts don't. It's a necessary improvement of the drc script. I've found a bug. It detects small metal2 boxes with the min area rule, but the box is surrounded by more metal, so the effective area is bigger than the minimum area.

@Andreas Krinke The script also detects a lot of errors in the digital layout (from OpenROAD) of another project we have.

@Krzysztof Herman this is the thread where the DRC issue is being discussed

@aquiles viza Ah ok, so my fix isn't working as expected. I have to check again.

Hi @Andreas Krinke, I've found another bug on the script The detection of the rule

TGO.a: Min. ThickGateOx extension over Activ = 0.27

only happens on the Y axis, not on X

I think this is the intended behaviour of

TGO.a

. The minimal extension is only checked where ThickGateOx extends over Activ.

Ahh I get it now. It doesn't enforce enclosure

@aquiles viza I cannot reproduce the

M2.d

errors. I overlapped two boxes on Metal2: One very small box (triggering

M2.d

) and one large box (not triggering

M2.d

). The DRC script from this thread didn't find an error. Can you provide a link to the layout file?

Hi, in this gds the min area criteria is triggered but it should not

Thanks! This was an interesting bug. Turns out adding a shape on layer

EdgeSeal

prevents

M2.d

errors. I've found the cause – could you try the attached DRC script?

Hi @Andreas Krinke, I've tested this script with our design and the DRC errors goes down to one that might be a bug. The script detects

NBL.a: Min. nBuLay width = 1.00

on a region with Nwells, not NBuLay. Also, it's inside digital logic generated with OpenROAD. Maybe this is not a bug because NBuLay is a layer generated on certain conditions. DRC says `(...) Furthermore, nBuLay may be generated automatically within NWell (see 4.2) in order to reduce the resistance of the NWell.`Maybe we can avoid this with

NBuLay:block

, but it's odd that OpenROAD Flow Scripts did not handle that condition. This GDS throws a lot of errors, ignore all but

NBL.a

@Krzysztof Herman @Daniel Arevalos

Yes, according to the layout rules

nBuLay = nBuLay + (NWell ≥ 3.0 µm) sized by 1.0 µm/side

. However, maybe our implementation is wrong. We currently size

NWell

first by

-0.5 µm

and then by

+0.5 µm

. When I think about it, maybe we have to size by

-3 µm

and then by

+2 µm

? Then we would only consider

NWell ≥ 3.0 µm

and size by

1.0 µm/side

.

@Andreas Krinke please review also

M2Fil.b

rule, it gives me al lot of false negatives. The spacing I have set for fillers is 0.55 and indeed it is on the layout Min. Metal2:filler space = 0.42

Do you mean the DRC finds

M2Fil.b

errors although the filler spacing in the layout is 0.55?

yes

I cannot reproduce the issue with a simple test layout (an array of boxes on

Metal2.filler

).

M2Fil.b

is implemented using the KLayout default spacing check with min space = 0.42. So I am not sure what is wrong. Can you provide a simple test layout?

I will. I found also other issue with

Cnt.a

rule. Ito does not detect contacts which are 0.5x0.5 um . The testcase can be found here https://github.com/IHP-GmbH/TO_Nov2024/pull/12

Hi all, there's any pull request with the upgrades shown in this thread? @Krzysztof Herman @Andreas Krinke

Not yet. I will update the open pull request for the Klayout DRC script in the next couple of days.

That's great! Please keep me informed

@Krzysztof Herman Thanks for the reports. The

M2Fil.b

bug has already been fixed in the DRC script pull request (which is still open because I have to incorporate some feedback) and in the DRC scripts in this thread. The issue with

Cnt.a

was a little bit more complicated. I have fixed the bug in the attached DRC script. Contacts with a size of 0.5um x 0.5 um now violate

CntB.a

. I will update the PR to include all the fixes from this thread and the feedback.

Hi @Andreas Krinke how are you ?

Hello Krzysztof! Thanks, I'm fine – a lot to do for the DE:Sign Challenge call that is due at the end of March 😕 - how are you? Yes, I know that efabless shut down. Thanks for the pointer to fossi-chat.