Pad.kR rule vs openroad PAD

[britovski]

Environment

klayout 0.29.7

Expected Behavior

DRC clean?

Actual Behavior

144 Pad.kR rule violations

Steps to Reproduce the Problem

1. Just open bondpad_70x70.gds from https://github.com/The-OpenROAD-Project/OpenROAD-flow-scripts/tree/master/flow/platforms/ihp-sg13g2/gds
2. Run DRC maximal

I saw that is an expressed rule on SG13G2_os_layout_rules manual that says: "TopVia2 under Pad not allowed (Note 3)" Note 3. TopVia2 may be damaged during packaging process, we recommend not to use them below Passiv.

The openroad PAD has stacked all metal layers to easy the connections from the chip but how can deal with the note 3 about the violation?

[noherbrferurtth]

Hi,

so far we used the Bondpad GDS for all our Tapeouts and had never issues with wire- or flipchip bonding. I will check internally if we can modify or remove this note or if i missed anything here. However, we never got DRC error on the pad.

Best

[smunaut]

Same errors here.

I also have others which I think are coming from that bondpad as well :

Pad.d1R: 100
Pad.fR_M2: 100
Pad.fR_M3: 46
Pad.fR_M4: 46
Pad.fR_M5: 46
Pad.fR_TM1: 46
Pad.fR_TM2: 67
Pad.kR: 4600

[akrinke]

If Pad.kR is no longer necessary, it should be removed from the Layout Rules Manual. Then we can remove it from the DRC script.

[dnltz]

I can confirm I also see Pad.kR and Pad.d1R in my design. @KrzysztofHerman ran the commercial DRC and it didn't report those. Seems to be related to the open DRC.

[akrinke]

That's interesting. @KrzysztofHerman Is there something wrong with our implementation / understanding of Pad.kR?

[smunaut]

The "rejection test" thing on the web ui for submission definitely reports Pad.kR to me.

[KrzysztofHerman]

I have just run the bondpad_70x70.gds cell using proprietary and Klayout's DRC. The only one appearance of Pad.kR appears for Klayout's maximal rule set. @akrinke could you please review the implementation ?

[KrzysztofHerman]

@akrinke the detection of this violation is seems to be correctly implemented. Nevertheless maybe we could think about additional section in the rules related to recommendations. If you red the description carefully this rule is a recommendation and it is related to the probability that the vias will get damaged during the wire bonding process.

[KrzysztofHerman]

@britovski going back to your concern about the Pad.k rule you could eventually use an exit from the bondpad structure (following Pad.e and Pad.f rules) and use vias outside it. Thus you would ensure 100 % reliability.

A practical example:

[akrinke]

@akrinke the detection of this violation is seems to be correctly implemented. Nevertheless maybe we could think about additional section in the rules related to recommendations. If you red the description carefully this rule is a recommendation and it is related to the probability that the vias will get damaged during the wire bonding process.

It is already defined as a recommendation. If you run the maximal DRC script with -rd noRecommendedRules=true, this rule won't be checked.

[sergeiandreyev]

The "rejection test" thing on the web ui for submission definitely reports Pad.kR to me.

@smunaut, could you please send an email with the attached report?

[sergeiandreyev]

one more comment regarding the "rejection test" thing on web ui reports Pad.kR during the rejection test from the web UI actually two DRC runs are made in parallel:

• the 'real' rejection test with tool x and rejection test-specific (short) list of DRC rules -> this is a run for IHP to decide if the design can be forwarded to manufacturing process, the GDS must not have any critical errors!
• the 'extra' DRC run w/ tool y and full set of DRC rules from commercial PDK -> this is a run for 'customer' to cross check that the results of a DRC run are the same as he can see on his side using commercial tools/PDK

[sergeiandreyev]

Pad.* are part of the full set of DRC rules, but are not part of the 'short/minimal' DRC rules