https://open-source-silicon.dev logo
Join Slack
Powered by
Whats the best documentation about the metal densi...
# magic
w
Whats the best documentation about the metal density rules / checks for SKY130? Really the only reference I am finding to it online is here and they do not post the scripts they provide nor can I seem to get magic to throw errors for areas that are reported as what should be over the density limits https://github.com/Avnish21/VSD-Physical-Verification-Using-Sky130/blob/main/README.md
t
There is a special script that runs density rules in magic, because magic can check density of any layer, but it doesn't have a way to encode the rules. So the script runs magic's density check and then says whether the result is pass or fail. There is also a similar klayout script that (I think) is in the precheck repository. Note that the main hitch with density checks is that they have to be run on the top level after fill pattern generation. If you run prior to fill pattern generation, you can catch any errors for over-density, but it will give false positives on under-density, indicating that fill patterns need to be added. There is a script for adding fill patterns, too. Ultimately this should be done on the top level only, but you can get a reasonably good approximate result on any size cell. Both the fill generation script and the density check script can be found in open_pdks and are installed under 
libs.tech/magic/
. They are also in the caravel repository under the 
scripts/
directory.
w
Right now I am just worried about over-density on my waffle fet designs. Looking through the scrips it seems that the density checks are run on a 700um box that is stepped in 70um increments? And the density limits are actually hard coded into the check density script, not the rule deck?
I know there were metal density issues with my design that were uncovered after I submitted my design files. What did you do to work around them? Did you just have it skip the checks? As I have solid ~700umx700um squares of metal, so it should pretty obviously and badly fail the metal checks
Given that even the largest waffle fets are <<700um I think I should be ok on the density checks.
I want to do some basic checking though, so I have a few questions. Looking through the script I see lines like
Copy code
set m1dens [cif list cover m1_all]
but on trying that syntax I get
Copy code
CIF name "m1_all" doesn't exist in style "gdsii".
Also, looking through the script it seems that the cif list cover command should list the coverage in a drawn box. But on running that on my own design it seems to be using the bounding box of the design or something, not any drawn box.
I am trying this on the .mag file, not an exported GDS. Will this only work correctly on GDS?
t
It runs on the .mag file but the calculations are done on the GDS layers. You need to do 
gds ostyle density
before attempting to run 
cif list cover m1_all
because the (derived) layer 
m1_all
is defined only in that style.
Solid metal layers of 700um x 700um will fail density under normal circumstances. I thought all of your waffle FETs had diagonal stripes of metal that had more or less 50% density. According to SkyWater only the FOM (diffusion) is measured at 70um steps. All metal layers are just measured at 700um steps (so no overlap). That leads to potentially position-dependent density results, but that's how they define it.
w
Copy code
% gds ostyle density
"ostyle" isn't a valid gds option.
is there some command I need to run on the .mag file to generate the GDS file first?
I just want to check the approximate density of the different layers of my waffle fet to see how well it would integrate into final designs.
I think the diagonal runners are a pretty high fill factor. But my final design had 700um+ squares of solid metal between the waffle fet edges and the connections to the I/O pads
t
Sorry, the command is 
cif ostyle density
.
w
Ok, I read through the script some more and I see how it cuts the design into tiles and loads them as a independent design. So I have checking an arbitrary part of my design down.
It looks like my core design is pretty dense on M3 - M4 (84.5%), but this should all be ok as the switches are all much less than 700um across.
I am worried about the FOM (diffusion) though, as that is checked over a smaller area and a somewhat poorly cropped selection of my core switch is right up against the limit.
What actually is the FOM limit checking? I am not sure where to find these on the SKY130 documentation page. Is it just N diffusion? does it include stuff like the diffusions for substrate / well taps?
Also, sorry for all these questions. If there is documentation on this please just tell me to go read through it. However, I am under the impression that this is one of those things that there is not currently much documentation written about
Huh, the core grid seems to be over the FOM density limit of 57%. So whatever that is I guess I need less of it
or to get very lucky in positioning the fets so they are between grid squares and never more than ~140um wide
t
Yes, FOM density checks include all forms of tap and diffusion. You can try adding a surrounding ring of type 
obsactive
around the FET core to prevent FOM fill shapes from being generated near the FET, which will then average out to something in the nominal range when averaged over the whole 700 x 700 area, since you say that the FETs are always smaller than that.
w
FOM is checked at a 70um step though, right? So the fet itself needs to be below the upper FOM density limit (and I guess above the lower limit because it would be hard to add filler cells inside the grid
Looking at the fill script it just looks like it adds filler cells to any empty area and the density of the filler cells is chosen to be between the two limits, such that it should average out with the user design to be between the user limits?
So an area of very high density may theoretically be able to meet the density requirements with no filler cells but the current filler cell script will cause it to go over limit?
I changed my tap regions for each waffle fet cell and my main guard ring so I should be within the FOM density limit. Just figuring out how low I should try to bring the metal density now
Also, I think I am doing something wrong or magic is counting the metal layers and the vias independently towards the metal density limits? This is reporting as
Copy code
% cif list cover m1_all
0.8046990633010864
% cif list cover m2_all
0.5786654949188232
% cif list cover m3_all
0.9799643158912659
% cif list cover m4_all
0.9799643158912659
% cif list cover m5_all
0.8006564974784851
%
Its a little bit of an approximation, but the M3/M4 runners are ~ 0.71um space and ~3.18um width, so the asymptotic density should be ~82%. 97.9% seems way too high, even if my math is off, there is no way it looks like a 97.9% M4 coverage in that image
nmos_waffle_8.mag
nmos_waffle_8.mag
@Tim Edwards sorry to bother you about this, but it seems there is some bug in magic about the metal coverage on the diagonal runners. I think it might be an issue with magic and diagonal fill again? Just checking the MET4 density it also reports ~97.9%. If I delete a small portion of a metal runner if jumps down to a much lower value, like 91% or so (but still higher than I expect). So it seems something with the cover area calculation is not correct
Here is the cropped tile that has ~97.9% M3 and M4 coverage when first loaded
tile.mag
If I even draw a M3 or M4 area outside the tile and delete it the M3 and M4 coverage updates to a lower value (~94.7%).
Looking through the check density script I dont think I am missing any magic commands to set the coverage check commands to run correctly?
Oh, huh. If I run
Copy code
drc check
on the cropped tile before checking the metal density I get 85.8%. Which seems plausible-ish
So I guess the core issue is that
Copy code
cif list cover
does not operate correctly if there are un-flagged DRC errors
Dont know if thats expected behavior or not, but I can work around it. Sorry for the bother!
@Leonardo Gomes
2 Views
Open in Slack
PreviousNext
Powered by