Missing Cont in IO cells

[dnltz]

I have a design with IO ring and DRCs report LU.d and LU.d1 violations. Both rules are defined as following:

As you can see in the next image, all violations are located in the IO cells itself. It looks like there is quite some Cont missing. (Image is showing the LU.d violations).

We taped-out these cells in May and used Cadence for Metal fill. We also had no LU.d violations in that tape-out. So, seems like Cadence is smart enough to fill the missing Cont filler.

However, I would propose to add the missing Cont to the IO cells directly. It's probably easier to just add it once instead of filling it in each design.

---

The following image is showing the LU.d1 violations:

[dnltz]

If someone could fill the sg13g2_io.gds file for me, I'm happy to try them!

[sergeiandreyev]

@stafverhaegen-chipflow, could you please take a look?

[stafverhaegen-chipflow]

@dnltz, I agree that it would be better to add contacts also in the corner cell of the IO ring. Reason it's not done is that my current layout generation code does handle the generation of the Activ to Metal1 contact array in this corner cell due to the 45 degree part of the taps. I will add it to my TODO list of improvements.
Unfortunately I need to sync this development with other development to not overwrite manual changes done to the gds and I am busy with an SRAM test chip for the Nov. tape-out. So unfortunately this change won't be ready for this month's tape-out.
Given the big width of the n-tap and p-tap in the corner cell and thus low(er) resistance and that no switching devices are present in the corner I think this error can be waived for the moment.

[sergeiandreyev]

@dnltz, we have the IO Layouts with contacts in our internal OA database, we need to upload them to the GitHub repo
unfortunately, it takes more time than expected due to additional consistency checks that have to be run and various parallel activities

[KrzysztofHerman]

@dnltz @stafverhaegen-chipflow @sergeiandreyev I have checked today all the IO cells running DRC using klayout and maximal ruledeck. Below goes a list of cells which reported issues:

sg13g2_IOPadAnalog
sg13g2_IOPadIOVdd
sg13g2_IOPadIOVss
sg13g2_IOPadIn
sg13g2_IOPadInOut16mA
sg13g2_IOPadInOut30mA
sg13g2_IOPadInOut4mA
sg13g2_IOPadOut16mA
sg13g2_IOPadOut30mA
sg13g2_IOPadOut4mA
sg13g2_IOPadTriOut16mA
sg13g2_IOPadTriOut30mA
sg13g2_IOPadTriOut4mA
sg13g2_IOPadVss
sg13g2_IOPadVdd

Usually the cells report same issues seen on this screenshot:

It is kind of systematic error which should be easy to fix using the generation scripts.

[dnltz]

@dnltz, we have the IO Layouts with contacts in our internal OA database, we need to upload them to the GitHub repo unfortunately, it takes more time than expected due to additional consistency checks that have to be run and various parallel activities

@sergeiandreyev Alright. Please let me know when you opened the PR and I can check them as well.

[stafverhaegen-chipflow]

It is kind of systematic error which should be easy to fix using the generation scripts.

Agreed, plan is to have layout DRC clean for maximal deck in next iteration. Unfortunately as said earlier won't be ready for tape-out of this month.