hello @Tim Edwards We are trying to submit our SSCS PICO design, but we get killed by the .gds being too large for Github to directly manage it. We have tried to upload it using "make compress", which compresses and splits the original .gds in two .gz files. After this, we tried to run precheck both in the platform, and locally. In both cases, online and locally, the Klayout BEOL step takes a huge amount of time - I'm not sure anymore if it is doing anything, since it didn't stop yet and didn't produce any reports. Therefore, we can't complete the precheck step and risk not to be able to submit our design before the deadline next monday 14/11. Our design is quite big because we use .tcl-scripted power switches layouts which are flattened. The strange thing is that we have a previous version of this "flattened" design with 80MB size (after compression), and this design passes precheck without problem. The latest design only adds some routing and few other modifications, and for some reason the file increases its size to 108MB (after compression, and then this is compressed+splitted and gets stuck at the Klayout BEOL step as explained above). Also, the latest .gds file should be even better in terms of size because some blocks are now hierarchical. We are quite confused about how to figure out what we are doing wrong. Are there any practices that should be avoided to get manageable file sizes, apart from hierarchy? Any ideas on how to debug this issue?

Can I you point me to the

.gds

, I would like to take a look.

Hello @Harald Pretl, thanks a lot for replying The GDS files are here: https://github.com/JorgeMarinN/3LFCC_AC3E_Tapeout/tree/sscspico/gds

The GDS is ca. 600MB, does that sound right?

nope sorry, that one is .gz, but you can do

gzip -d file.gz

I think I see where the problem is. First, a GDS of 600MB is likely really straining the tools.

yup, @Alfonso Cortés is working on this... but then we realized that the size increases quite a lot only with routing and few changes and we thought there was something else going on. We will try to finalize it. nevertheless, it's strange that the precheck pases for a design with these structures and not to different from the latest, and that it fails or takes ages for the latter... do you know what could be the reason? do small changes matter a lot if there are flattened structures?

I think this design is a corner case, which @Matthias Köfferlein and @Tim Edwards should use to look into, and see where

klayout

and

magic

have potential issues, and improve it. I suggest to file tickets for both tools after the tapeout.

Magic DRC and Klayout FEOL pass, but Klayout BEOL gets stuck... it has been running for almost 24h in the platform now 😑 Do you know if there are any emergency alternatives to run these checks to avoid missing the tapeout? it would be really a pitty...

Not really. But this is is a hint: If FEOL is OK and BEOL struggles, then I bet on klayout having an inefficient DRC implentation of 45deg structures. Usually, there are only very if any 45deg structures on a chip. A lot of technologies don’t allow time. Usually the only place for these is in on-chip inductors.

If you have narrow spacings on 45 degrees like the above, and you're doing it in magic, there's an option to write polygons to GDS. It takes a lot longer to write the GDS because following a non-manhattan edge in magic is a non-trivial operation. But the result will be handled better by other tools. Definitely layout should be hierarchical whenever possible. There is no reason to flatten layout except for some things like full R-C extraction which usually does not work well with hierarchy. But for such things the layout should be flattened temporarily for the specific thing it needs flattening for, not flattened permanently.

BTW, the cap array is also huge, but here it seems like implemented as an array, so this should be OK. Plus everything manhattan (thanks @Tim Edwards for reminding me of the correct term, much better than zig-zag :-)).

@Harald Pretl: The klayout deck is the definitive set of manufacturing rules that result in a go/no-go decision by SkyWater. Magic does not have an exactly corresponding set of rules (I've never developed such a rule deck for magic). So there's no way to implement a "switch" between klayout vs. magic. If a rule is written in such a way that it is ridiculously inefficient in klayout, which is probably the case here, then a github ticket in the precheck repo is a good idea. Usually the rule can be rewritten in a way that doesn't take forever to run.

@Tim Edwards what is the correct magic command to write a gds with polygons, as you suggested?

The option is

gds merge true

. The drawback is that the option makes everything into polygons, which is why it takes so long. It would be a lot more efficient if it just wrote polygons for the non-manhattan parts (technically, everything is written as a polygon in GDS, but magic's database is in tiles, so it just dumps tiles to GDS and everything is either a rectangle or a triangle. Long non-manhattan wires are then lots and lots of triangles and rectangles.)

@Tim Edwards If the checks runs forever, I assume it blows up memory usage to the point where swapping kicks in, and then it will take absurdely long.

Not necessarily. There are ways to inadvertently create a rule that runs in O(N^2) without realizing it.

hello @Tim Edwards, thanks a lot for the info is gds merge true being done implicitely, or we need to do it manually?

It's an option you need to issue as a command before doing

gds write ...

how long is very, very long? we have been waiting for the precheck for almost one day now, if it's less than that, it's still better

Problem is, I don't know. I have not benchmarked it.

@Jorge Marin @Tim Edwards I am just testing it, give me a few minutes. I think it is almost done.

also: what is VERY weird is that both situations, flattened layout and 45° metals, were present in a .gds version that managed to pass precheck before

@Tim Edwards magic says “completed 50%” on a gds write… what does this mean?

May mean that it was 50% done, but it may be may be assuming linearity on something that is nonlinear, so it may or may not mean it's halfway through (it doesn't output at 100%, so it's done when the prompt comes back).

@Tim Edwards 😳

also, these power switch designs which contain these features were taped out and fabricated before (by Weston Braun)

@Jorge Marin I guess something tripped a corner case, which is not unusual, even with commercial tools. I am not surprised, I’ve seen many strange things in complex SW.

Yup, I see, I also thought so...

@Jorge Marin @Tim Edwards magic now at 75%, which may or may not mean that it will finish soon (to quote Tim :-))

nice! thanks a lot Harald, we'll try this :)

Of course, that may not solve the issue at all. I'm just trying to think of things that might make the database not get bogged down by (what might be) a poorly-implemented DRC rule.

Compression rate (gzip) of both GDS is also almost the same. I guess worth a try to check this GDS in the precheck, but better implement the zigzag metal.

OK, I'll try this quickly, otherwise we still have one more possible workaround thanks to both!

Hello @Tim Edwards @Harald Pretl There are no major differences between the layout of our last .gds (that passed the precheck, with 450 MB) and our current one, that weights over 610 MB (even if our main subcell is 50 MB lighter than before). I determined that the bonding pads that we added are responsible for over 200 MB in the .gds The layout of these pads is done with:

box 142.8um 3411um 442.8um 3511um
paint {metal1 metal2 metal3 metal4 metal5}
box 143um 3411.2um 442.6um 3510.8um
paint {m2contact m3contact via3 via4 glass}
box 642.8um 3411um 942.8um 3511um
paint {metal1 metal2 metal3 metal4 metal5}
box 643um 3411.2um 942.6um 3510.8um
paint {m2contact m3contact via3 via4 glass}
box 1142.8um 3411um 1442.8um 3511um
paint {metal1 metal2 metal3 metal4 metal5}
box 1143um 3411.2um 1442.6um 3510.8um
paint {m2contact m3contact via3 via4 glass}
box 1642.8um 3411um 1942.8um 3511um
paint {metal1 metal2 metal3 metal4 metal5}
box 1643um 3411.2um 1942.6um 3510.8um
paint {m2contact m3contact via3 via4 glass}
box 2142.8um 3411um 2442.8um 3511um
paint {metal1 metal2 metal3 metal4 metal5}
box 2143um 3411.2um 2442.6um 3510.8um
paint {m2contact m3contact via3 via4 glass}

There are 5 pads, which means each pads weights about 40 MB. Since they are identical, I will make a subcell. But 40 MB still seems too heavy for a pad that is made of only 10 rectangles.

@Alfonso Cortés: In this case you will probably get a much smaller GDS if you use the

gds contacts true

option. This will output contact cuts as an array instead of individual cut rectangles and is best for a large array of contacts like your pads. I do not use this option much, so please let me know if it has any issues.

@Alfonso Cortés If

magic

resolves these huge via areas in the pads into individual rectangles, then you should make a small cell containing the vias (ideally containing the whole metal-via-stack), and then array this smaller instance into the pad area. Then the resulting GDS will be much smaller and hopefully runs smoothly. @Tim Edwards I think you should put this setting by default into

magic

that large via areas are built out of smaller arrayed structures.

@Tim Edwards With

gds contacts true

I get the exact same file size. I only see that the perimeter of the vias changes a little. How can I check the effect of using this option?

@Alfonso Cortés: While I think that the best solution is to keep the layout as hierarchical as you can, I'm interested in the problem of why this output is so large and why the various suggestions I made have no apparent impact on that output. I assume this layout is in a repository---can you point me to it?

This is the layout I made for a single pad. I get the same file size for the GDS, with or without the contacts option.

My observation testing it is that the command

gds contacts true

caused magic to generate subcells for each of the contact types used in the pad, and then it failed to use those contacts and wrote out the same output as without the option. I'll need to fix that, but I'll assume that the solution you made works for now. I think a better solution in magic would be to enforce the

gds contacts true

always, and try to optimize that method for speed.

@Tim Edwards I think even when after gzip of the GDS there is no difference the change is worthwile, as not all GDS will be compressed right away.

hello @Tim Edwards @Harald Pretl, thanks for the checks on our side we tried @Harald Pretl’s idea of generating a minimum cell to the pads to get hierarchical optimized layout. It looks fine and passes DRC, but when sending it to precheck, we get the failure message attached below. It seems to try to find the power_pad structure in the netlist, which is just a node. We will check this, it's probably an error from our side, but any comments are welcome. The most worrying part is that the Klauoyt BEOL precheck still gets stuck, it's still running since yesterday. This is definitely a showstopper for us. We were wondering if leaving just metal5 and opening, with the required vias for the metallization, would be enough for having pads in the user area. Our current layout includes all metals and vias in a 100umx300um area, which of course is a lot of via poligons. Any advice or comment would really help!

@Jorge Marin: You need to check with the guys running the precheck (try @jeffdi, maybe) on what the requirement is. The preferred netlist format is SPICE, I think, but I also think there may be issues with the way they are doing the precheck. I have tried to relate to them several times that they cannot just do a one-to-one comparison of subcell names, that nothing short of a full LVS can definitively determine whether a netlist matches the layout. But the precheck does report this as a "warning", so I'm not sure if that's what is actually causing the precheck to fail?

Hello Tim, I don't think so, we have a previous version which is passing the precheck. Strangely enough, the passing version has already some pads laid out in the old way (with big via rectangles, not with subcells and hierarchy), and it doesn't complain about it. We tried a new version with the problematic pads but with only one tile line with vias, to see if we are somehow exceeding the number of via elements the Klayout BEOL can deal with, but it's again stuck in the online BEOL precheck step. I have the feeling we are triggering some issue here, but I'm not sure how to debug it.

I would expect that it needs to be debugged on the Efabless end, so please file a ticket with Efabless to check why the precheck won't finish.

how can I file a ticket with Efabless? sorry, I should know this maybe...

I'm not sure if you can file a ticket from the submission process. There's the helpdesk ticket system on the Efabless platform, although I think the best thing to do is to contact @jeffdi (bear in mind that it is only 6:00am in California right now).

OK, thanks What's the best way of contacting @jeffdi? via DM on slack?

Yes, DM on slack.

I ran BEOL directly from Klayout (with the sky130A_mr.drc file), to see where it gets stuck, and it was in this line

m3.enclosing(via3, 0.06, euclidian).output("via3.4", "via3.4 : min. m3 enclosure of via3 : 0.06um")

Could it be that making our pads as arrays of small instances is increasing the computational cost of checking these VIA rules? @Harald Pretl

I am not sure. Usually, tools recognize repeated structures and use this to lower the computational effort. Maybe @Matthias Köfferlein has an idea.

Hello @Tim Edwards and @Harald Pretl, after a lot of work to make the design hierarchical (thanks to @Alfonso Cortés) and check through the platform, we managed to generate our first functional gds file which passes the online precheck. Unfortunately, this design is not passing the Tapeout phase, and it's impossible from the logs to understand what could be wrong. Do you know how to debug this? which extra checks is the tapeout step doing? I can't find a "main" log that describes the check results and why it fails. Your help would be highly appreciated!

Hi, @Jorge Marin congratulations on passing the pre-check! Unfortunately, I have no information about the tape out procedure that is run by efabless. If there is a log, I can try to help interpret it. Otherwise, it is up to the efabless folks @Tim Edwards @jeffdi to support you on this.