@User @User I am doing precheck on the user_analog_project_wrapper after combining 3 projects. I have run the local precheck as well as the one on the efabless site. All the checks are clear except the Klaoyut FEOL which is throwing 383 DRC violations even though magic does not detect any. The xml file generated in the reports folder during the check is not readable by the klayout marker browser. So I am not sure how to solve this issue.

Magic does not check density automatically or as part of its DRC checks, but it does have a density checker, and there is a script

check_density.py

in open_pdks (sky130/custom/scripts) that will run it. That can probably help you figure out where the density issues are. FEOL density checks will only check for density of (diffusion + tap) layers. It may be necessary to run the fill generation scripts first, but I think the klayout FEOL density check is just looking for density that is too high prior to running the fill generation scripts (since there is nothing the fill generation scripts can do to remove diffusion layers; it can only add them). In that case, the over-density error should show up in magic's check.

Thanks for the response @User. I looked at the xml file. There are 3 kinds of violations: hvtp.1, hvtp.2 and npc.2. All 383 violations are of these categories. All of these seem like they should be flagged in magic. what could be the issue ?

Magic doesn't check these because it's supposed to generate them, DRC-correct, unless that's subverted by doing "cif *hier write disable".

How should I resolve these errors?

How do you generate final GDS of your user project?

From the file menu ->write gds in magic

Can you point me to the repository so I can check the layout? Magic does sometimes fail to produce DRC-correct output, and that can be worked around, but having hundreds of such errors is unlikely and suggests a more fundamental problem.

@User the tap cells were added at a distance of 30um apart in each row, such that they could cover up the 15um on either side, filler cells were added as well to cover density and well errors. Then what could be the possible reason for these errors and their solution?

You should use decap cells for fill, or a mixture of decap and fill; if you use "fill" cells only, your design is likely to fail FOM density checks.

Does that mean we should generate a new GDS for the digital macro?

we have used both fill cells and decaps. There are Decaps totaling about 13.4 pF capacitance.

@User I suspect the problem is with the magic contact generation method. I was finally able to load the violations reported by the precheck in the klayout marker browser tool. The sample pics for all 3 categories (hvtp.1, hvtp.2, npc.2) are attached. There are almost 330 violations of npc.2 and in almost all the cases the distance between the contacts is 0.265 (should be 0.27) and in case of hvtp.2 most of the errors are because of diagonal length(should be atleast 0.38). In case hvtp.1 magic is making connections with very small width (should be atleast 0.38).

@User: Magic has rules to ensure DRC clean layout of HVTP and NPC layers, so the only way to get issues like the above is to purposely disable the hierarchical GDS processing.

I dont think I have intentionally disabled that. From the

user_analog_project_wrapper

, what is the correct way to generate the final gds in magic?