Hello All, we have a problem with resubmission of out MPW-7 tapeout. It passes precheck, but fails density checks in tapeout job AFTER Caravel integration and metall fill. Density values reported by tapeout klayout_met_density.log are on the screenshot. It looks like metal fill scripts "overfilled" M2 & M5 a bit. Is there a workaround which could be applied to our GDS to mitigate this issue or nothing can be done without metal fill scripts changes?

I got same issue in MPW8. https://github.com/whutddk/Rift2Go_2330_Sky130_MPW8

Do you know where we could create an issue for this problem? There seems to be no public github repo for tapeout or metal fill scripts. @jeffdi

@Egor Lukyanchenko As caravel is common to all the project, exceptation is user project owner reduces these density to meet to Tape-out checks.

The problem is that it seems to fail not before, but AFTER metal fill. So it's not project or Caravel, but metal fill script issue.

I believe that

ca_density

is the clear density (the inverse of the regular density). So the m2 density is < 35% and m3 density is less than 40% after fill. Do you have large areas of the layout that block m2/m3 fill?

There is nothing in GDS that was put there to block metal fill. Final GDS and macros were all generated in OpenLane, no analog design, etc. You can find it here https://github.com/egorxe/miranda_fpga_openmpw/blob/main/gds/user_project_wrapper.gds.gz . This GDS passed all checks during MPW6 and original MPW7 tapeouts. M2&M5 densities during precheck also seem to have large enough margin (see images).

@Egor Lukyanchenko Thanks for bringing this up. It looks like 2 months ago, the precheck density rules were updated to include more layers in the calculation. For example, previously just the drawing layer was included

m2_wildcard = "69/20"

but currently

m2_wildcard = "69/0-4,6-43,45-*"

So this looks like it might additionally include

69/10

metal2 blockage

69/60

via2 boundary

69/16

metal2 pin (data/text)

69/0

metal2 pin (text)

69/14

metal2 cut

69/25

metal2 probe

69/15

metal2 short I believe that all the data is merged so it’s not double counting. Is there final oas data created by tapeout that you can view? For metal2, the fill layer is

41/28

Maybe display metal2 drawing

69/20

and

41/28

and see if there are any unexpected open areas. I’ll ask around. @omla any ideas?

@Mitch Bailey Thanks for looking into this! By looking onto Oasis on Open Galaxy (tapeout ab7b13dd-56a8-4e15-89da-5b9ca2b410cf) I do not see any large scale empty areas. The only discrepancy on 69/20+41/28 I was able to notice was a strange pattern without fill shapes on small scale going in squares 700x700um with width of 4um. This pattern does not correspond with anything in my design and seems to come from box size in fill script (https://github.com/efabless/caravel/blob/38492d9da4071eef2b9a32029fa9d4778a698cc1/scripts/generate_fill.py#L174). However I'm not sure if this small discrepancy could lead to wrong final metal density.

That’s how they’ve implemented the tiling - large square regions with a slight gap between them. For your M5 screen shot, I see a somewhat abnormally long horizontal gap in the lower right. Any clue as to why that would occur?

Not really. Here is a zoomed screen of this place. May be it needs a smaller fill shape to fit in this gap?

Probably. I notice that the paths have different widths. Are these auto routed?

Yes, wide ones are horizontal PDN stripes and narrow ones are regular signal routing.

@jeffdi density checks are failing by less than 1%. Is it possible to waive the requirement?

@Mitch Bailey @jeffdi It would be even better not to waive any requirements, but to run some kind of additional fill iteration if possible. Is there a way to download oasis from Open Galaxy?

That’s what I’d recommend.

@Egor Lukyanchenko, @Mitch Bailey: Yes, I would recommend asking for a waiver for such a small (< 1%) discrepancy. SkyWater will typically move projects around to balance the density across the reticle. As long as we don't have too many failing projects, and they fail by only a tiny amount, they generally will still pass SkyWater's overall reticle density requirement.

@Tim Edwards Thanks for your comment! I've created github issue https://github.com/efabless/caravel/issues/397 and we've sent a message asking for waiver via "Manage my submission" form. Is there any other way I should contact Jeff with?

You can contact him on Slack, although he's pretty busy with the tapeouts right now, so he might not be very prompt in responding.

Hello, I want to know when will this issue be fixed? Is there any temporary solution? I have try to re-build the design with different

SYNTH_MAX_FANOUT

,

CELL_PAD

, but I still got same violation.