open-source-silicon.dev

image.png

<@U069XNVQM4H> this is the DRC issue for `aFil.g2`  - Min. Active coverage ratio for any 800 x 800 µm² chip area = 25.0 %

this looks to me like missing metal fill in the power ring and IO cells. Would Cadence fill these areas too?

The outer tiles at the top and to the right shouldn't be checked by `aFil.g2`. The tiles should be flush with the chip border. This is a problem we have to fix in the DRC script.

Hi <@U059HNXAWFK> and <@U073W5ECDQ9>. Thank you for accepting the invitation. I have also just receive the information that our seal_ring pycell should not implement fillers.

<@U073WEG1PEV> the issue with the active and OpenROAD is that can not control the generation of the active and GatPoly.  For metals it is simple because you provide the filler cells sizes and the respective rules in the json file. That was the reason to eliminate decap cells in the config file and use only fill cells which are supposed to meet the filler rules and respect other DRC rules.

btw I see similar issues with M1Fil.h up to M5Fil.h

if you have another DRC script, I'm happy to try it

20240515 sg13g2-maximal.lydrc

20240515 sg13g2-minimal.lydrc

20240515 sg13g2-maximal.lydrc,20240515 sg13g2-minimal.lydrc

give it a try. It was provided today by <@U073W5ECDQ9>

However, this new version doesn't change the way density checks work. So the bug I mentioned is still there.

yes, same result... <@U073W5ECDQ9> any idea when you could provide a new DRC file?

20240515b sg13g2-minimal.lydrc

20240515b sg13g2-maximal.lydrc

Try these. In your case, this update fixes the tile origin (the lower left tile is in the corner) and ignores the areas outside the chip boundary when calculating density.

<@U073W5ECDQ9> M2Fil still reports 21 issues. All other issues are gone related to the sealring

basically 30 issues in total related to fill with
1x GFil.g
1x M2.j
1x M5.k
21x M2Fil.h
4x M3Fil.h
2x M5Fil.k

I will have a look. Maybe these are valid DRC errors?

GFil.g reports Min. global GatPoly density error but there is nothing to fill anymore. Same for M2.j

This is true for the core, but what about the pad ring? The density check looks at the complete chip area.

I know but OpenRoad is not filling these areas

I will take a look — it's possible we misunderstood the rule.

or openroad is not working properly. There is only one design file with an IO ring

<@U018LA3KZCJ> could you please take a look ?

Please open an OR issue with a test case and an description of the problem.

I had another look and think the DRC errors are valid. The density limits apply to the pad ring as well.

<@U018LA3KZCJ> <https://github.com/The-OpenROAD-Project/OpenROAD/issues/5114>