Hello, is there a script/command for auto generation of fill in magic?

Take a look at the

generate_fill

target in the

caravel/Makefile

.

Also

libs.tech/magic/generate_fill.py

in the open_pdks installation of sky130.

How do I run the .py script in magic?

@Tim Edwards @Mitch Bailey We were able to generate the fills by moving all our magic files into the magic folder contained generate_fill.py, and then ran (from terminal)

python3 generate_fill.py <top>.mag

But how do we now align the generated fill gds with our top design? It looks like aligning the bottom-left (origin) corners on both doesn't match up...is there another feature/flag that needs to be used to align these correctly?

Does it need to be aligned? As long as it passes the overall density checks, I would think there would be no problem.

wouldn’t we need to instantiate our top design in the generated fill GDS or vice-versa, to get a final GDS on which we run prechecks, etc. ? This may require aligning, otherwise we may run the risk of shorting metals in our design to the fill metals

Currently, I believe fill is usually only generated once for the entire chip. Normally, the user project area is not filled before integration. However, I've heard that the project area can have pre-generated fill for critical areas. As you say, there may be a problem if the user generated fill overlaps with the caravel routing layer.

If the user generates fill themselves, then the full-chip generated fill will just see nothing left to fill in the user area and ignore them. From a standpoint of file size and execution time, it's better to leave the fill until the final step.

@Tim Edwards We were seeing density violations on m3/m4 in the pre-check which is why we considered running the fill script. If we don’t run the fills, is there a way to override density checks such that they are only run after the integration step and fill-generation (which will happen on efabless’s side?) Also we were looking at a possible 1.5 (or 1.5*2=3um) offset based on the box growing command on line 187…but we might have completely misunderstood this part! https://github.com/RTimothyEdwards/open_pdks/blob/master/sky130/custom/scripts/generate_fill.py#L186-L187

@Abhinav Uppal: The precheck density checks should only be checking for over-density, because that's detectable without running fill, and is something that cannot be fixed by adding more fill. Do you have over-density problems with m3 and m4?

@Tim Edwards it looks like a minimum “clear area density” violation. Does that mean we are over-density? This is what we get for our `klayout_met_min_ca_density_check.xml`:

<name>m4.pd.1d</name>
   <description>0.4 min m4 ca pattern density, m4 ca density is 0.38204002826315375</description>

Corresponding lines on the precheck.log are

2022-08-30 06:19:20 - [INFO] - {{STEP UPDATE}} Executing Check 11 of 13: Klayout Metal Minimum Clear Area Density

2022-08-30 06:19:23 - [ERROR] - Total # of DRC violations is 2 Please check caravel_analog_reram_crossbar/precheck_results/30_AUG_2022___05_58_23/outputs/reports/klayout_met_min_ca_density_check.xml For more details

2022-08-30 06:19:23 - [WARNING] - {{Klayout Metal Minimum Clear Area Density CHECK FAILED}} The GDS file, user_analog_project_wrapper.gds, has DRC violations.

@Abhinav Uppal: The use of "clear area" is annoying because it makes it much too easy to get it backwards. I have to look at my own scripts to figure out how to determine the density rule is defined. But "minimum clear area" means "maximum metal area", so you have too much m3 and m4 (more than 60% area) and it will have to be reduced.