https://open-source-silicon.dev logo
Join Slack
Powered by
<@U0172QZ342D> <@U016HSAA3RQ> <@U016EM8L91B> I am ...
# caravel
h
@User @User @User I am progressing on my MPW-5 tapeout, but I have a fail in min. density on LI1 (the only fail left in the TO procedure). Here now a couple of issues: • I look at the final oasis file (
caravel_00054fe4.oas
). By inspecting I find that the filling structures are on purpose 28, which is not documented here: https://skywater-pdk.readthedocs.io/en/main/rules/layers.html?highlight=28#gds-layers-information and not here: https://skywater-pdk.readthedocs.io/en/main/_downloads/b4838a38f1379533883c717f8f86d7b2/gds_layers.csv — Someone should please complete the layer docs in the above references. • When I look at the layers 56:0 and 56:28 then I find that the filling structures are there on 56:28, but nothing on 56:0 (CLI1M). However, the layer 67/20 (LI1 drawing) is really full. As I have no idea how I could increase density (and anyway it is automatically generated), I have the impression that the density calculation might be wrong, not taking into account filling plus user structures? Could this be?
m
Is this related to 
decap12
?
h
Not that I could think of. As the filling is done by the flow I don’t really know what goes wrong, I just see that the density of LI1 is at 38%, failing the min. 40%, but the chip is choke full of LI1.
Here a close up to better see:
So my feeling is that the density DRC is wrong, the density should be way higher than 38%, at least from eye-balling.
BTW, all other layers which are checked for density are clean, only LI1 has issues.
m
I believe with density checks, it's not the overall density that matters so much as the density in each 'window' that the rule looks at. My understanding is that the layout is divided into a bunch of smaller windows and the density is checked for each window. Can you see where the error flag is?
h
In my case it is not a tile but the whole chip. Here is the XML (and I double checked in klayout):
👀 1
m
That does appear to be the entire chip.
h
Do you know who implemented the density check in the efabless TO flow? Can you please forward this thread to him/her? Adding @User
m
I don't know. Maybe @User knows?
m
@User I looked at the klayout rule file and I think you are correct in that it looks like it computes the overall density, which is irrelevant. I don't think this is what is required by the foundry. The magic density rules look like 70um windows. I did find this discussion of doing gridded density checks with klayout. The pdk seems to indicate 50um window size with 25um step size. @User It seems that klayout's density check is irrelevant. (Although I may be mistaken.)
m
@User I don't know, but maybe @User can assist with that
t
(1) The entire chip density is, in fact, what SkyWater uses for all layers except FOM, which is done over tiles and needs to meet the requirement for each tile. (2) If the rule is "ca pattern density", the "CA" means "clear area" and refers to the density of areas that are not covered in metal (this is a bit wishy-washy, and we've had troubles keeping track of when "density" means density of fill shapes or density of clear area. Over-density of LI is very common when the original SkyWater decap cells are used for fill, because the decap cells are covered in LI over about 90% of the cell area. The best solution to this is to use the Efabless decap12 cell instead of the SkyWater decap 12 cell, where I cut back the amount of LI in the cell to about 50% of the area.
h
@User OK, my density is too high? (never heard of a “clear area density” before, but hey, never too late to learn something new) Any idea how I can trick OpenLane into using the efabless decap12? And where would this cell even be available (Update: found it)? Alternatively, how about dial down the amount of autofill a notch?
@User what if I blacklist the decap_12, and just use the others? I think this would be a quick, safe way by setting 
FILL_CELL
accordingly. now it is set to 
set ::env(FILL_CELL) "sky130_fd_sc_hd__fill_"
, I would change this to 
set ::env(FILL_CELL) "sky130_fd_sc_hd__fill_3 sky130_fd_sc_hd__fill_4 sky130_fd_sc_hd__fill_6 sky130_fd_sc_hd__fill_8"
Would this work?
t
Probably you want to ask the Openlane developers that question. I know that's more or less correct, but I don't have any examples in front of me. You want 
sky130_ef_sc_hd__decap_12
from open_pdks (installed along with the 
sky130_fd_sc_hd
cells). Another solution is a mixture of decap and fill, but that can cause a different issue by under-filling diffusion, which is why we have Efabless versions of the fill cells, too, with extra diffusion shapes to mitigate that problem (
sky130_ef_sc_hd__fill_12/8/4
).
Another solution is just to rename all the decap_12 cells in the GDS file directly from 
_fd_
to 
_ef_
. I have a script in open_pdks that will do a string substitution in a GDS file.
m
Thanks for the explanation, Tim. My understanding was that the density rules were to ensure that the chip was relatively flat after each fabrication level, but I am by no means an expert. So ca density is the opposite of mask layer density (ie. min ca li density of 0.4 means maximum li density 0.6)? The pdk has this which appears to be a stepwise maximum density. Do you know why overall density is a consideration?
h
@User It is quite common to have max and min density limits on etching-critical layers (poly, metals). By bounding the mix of “stuff” and oxide the fab people can keep the critical etch and polish steps better under control. Important is to have uniformity across the wafer (hence total chip density limits), the more critical the process gets, density checking windows get smaller and smaller, and nm-nodes almost impossible to fulfill by custom layout.
m
Harald, thanks for the explanation. I'm just trying to reconcile the window size in the pdk, 50umx50um, with the window size of the entire chip 3500umx5200um that klayout appears to use. I think I'm missing something.
h
#efabless @User I made a few experiments regarding my LI1 CA density issue on MPW-5. Just blacklisting the 
decap_12
still caused too low CA density. Then I tried to use the efabless’ 
decap_12
by including this in the `config.tcl`:
Copy code
set ::env(DECAP_CELL) "\
	sky130_fd_sc_hd__decap_3 \
	sky130_fd_sc_hd__decap_4 \
	sky130_fd_sc_hd__decap_6 \
	sky130_fd_sc_hd__decap_8 \
	sky130_ef_sc_hd__decap_12"
OpenLane runs and the GDS looks good, but the flow fails at extraction with:
Copy code
[ERROR]: There are illegal overlaps (e.g., routes over obstructions) in your design.
[ERROR]: See /home/harald/caravel_mpw5/iic-audiodac-v1/openlane/user_proj_dac/runs/user_proj_dac/logs/magic/36-magic_ext2spice.feedback.txt for more.
Any idea why, and how to fix it?
t
Blacklisting the 
decap_12
isn't going to work because OpenROAD still needs to fill the unused space; it's just going to use smaller fill cells instead, and they have the same problem. I'm not sure why the use of 
decap_12
causes overlap errors---it could be that the cell doesn't match the others in the way that it specifies which layers are obstructions, or the LEF view might not be correct. Can you figure out where the illegal overlaps are (it it is not clear from any output generated by Openlane, you can read the layout into magic and run extraction, which will leave "feedback areas" where it sees the overlaps. "routes over obstructions" is only one way to get that error. Mismatched abstract views seems to be the more common problem, though.
h
I just looked at the 
ef_decap_12
vs. the 
fd_decap_12
and there are a few changes, not just a reduction of LI1. So it would be an option to rework the 
ef
version by copying the original, and just reduce LI1. I tried also to extract manually in 
magic
, but this does not trigger the error, unfortunately. Not sure what happens here.
My suspicion at this point: The LEF has an issue vs. the MAG or GDS views of the 
ef_decap_12
.
I try now to fix my macro area, it is too large, so too many decap cells. If this fails I hack the 
ef_decap_12
in open_pdk and re-create the PDK, but this sound like too much work in the moment.
t
You looked at what view(s) of 
ef_decap_12
?
h
mag
t
I created the GDS for 
ef_decap_12
in exactly the way you mention, by simply editing the GDS layer for LI to scale it back, changing the name strings from 
fd
to 
ef
, and otherwise leaving it untouched.
In the .mag views in my PDK, the only thing that changed was the LI layer.
h
The label shapes look different, not sure if and how this could cause issues.
Is there I way that I can control the LI1 fill on the efabless tapeout procedure? The fill is rather dense, if I could just loosen it up a bit then all good.
@User BTW, the 
.gds
in open_pdks looks different label-wise.
t
Here are the checksums of the two GDS files, just to make sure we're talking about the same thing:
Copy code
md5sum sky130_ef_sc_hd__decap_12.gds
197f111bda68f16e425d978b560c99e3  sky130_ef_sc_hd__decap_12.gds
md5sum sky130_fd_sc_hd__decap_12.gds
cdc431dd1951c3cd0895edc58850ecc2 sky130_fd_sc_hd__decap_12.gds
The first layout you displayed above is wrong. The labels should not be in the middle like that. What version of open_pdks is that from?
h
this one, that is the one from caravel setup for MPW-5: -ne skywater-pdk c094b6e83a4f9298e47f696ec5a7fd53535ec5eb -ne open_pdks c5730b574461889c82858b08d12ba42423d9c2cb
this are the files that I have:
Copy code
harald@xserv:~/caravel_mpw5/pdks$ find . -name *decap_12*
./sky130A/libs.ref/sky130_fd_sc_hd/mag/sky130_ef_sc_hd__decap_12.mag
./sky130A/libs.ref/sky130_fd_sc_hd/mag/sky130_fd_sc_hd__decap_12.mag
./sky130A/libs.ref/sky130_fd_sc_hd/maglef/sky130_ef_sc_hd__decap_12.mag
./sky130A/libs.ref/sky130_fd_sc_hd/maglef/sky130_fd_sc_hd__decap_12.mag
./sky130A/libs.ref/sky130_fd_sc_hd/spice/sky130_ef_sc_hd__decap_12.spice
./sky130A/libs.tech/xschem/sky130_stdcells/decap_12.sym
./open_pdks/sky130/custom/sky130_fd_sc_hd/lef/sky130_ef_sc_hd__decap_12.lef
./open_pdks/sky130/custom/sky130_fd_sc_hd/gds/sky130_ef_sc_hd__decap_12.gds
./open_pdks/sky130/custom/sky130_fd_sc_hd/verilog/sky130_ef_sc_hd__decap_12.v
./open_pdks/sources/xschem_sky130/sky130_stdcells/decap_12.sym
./skywater-pdk/libraries/sky130_fd_sc_hd/latest/cells/decap/sky130_fd_sc_hd__decap_12.gds
./skywater-pdk/libraries/sky130_fd_sc_hd/latest/cells/decap/sky130_fd_sc_hd__decap_12__tt_100C_1v80.lib.json
./skywater-pdk/libraries/sky130_fd_sc_hd/latest/cells/decap/sky130_fd_sc_hd__decap_12__ss_n40C_1v35.lib.json
./skywater-pdk/libraries/sky130_fd_sc_hd/latest/cells/decap/sky130_fd_sc_hd__decap_12.cdl
./skywater-pdk/libraries/sky130_fd_sc_hd/latest/cells/decap/sky130_fd_sc_hd__decap_12.v
./skywater-pdk/libraries/sky130_fd_sc_hd/latest/cells/decap/sky130_fd_sc_hd__decap_12.svg
./skywater-pdk/libraries/sky130_fd_sc_hd/latest/cells/decap/sky130_fd_sc_hd__decap_12__ss_n40C_1v76.lib.json
./skywater-pdk/libraries/sky130_fd_sc_hd/latest/cells/decap/sky130_fd_sc_hd__decap_12__tt_025C_1v80.lib.json
./skywater-pdk/libraries/sky130_fd_sc_hd/latest/cells/decap/sky130_fd_sc_hd__decap_12__ff_n40C_1v65.lib.json
./skywater-pdk/libraries/sky130_fd_sc_hd/latest/cells/decap/sky130_fd_sc_hd__decap_12__ss_n40C_1v40.lib.json
./skywater-pdk/libraries/sky130_fd_sc_hd/latest/cells/decap/sky130_fd_sc_hd__decap_12.netlist.tsv
./skywater-pdk/libraries/sky130_fd_sc_hd/latest/cells/decap/sky130_fd_sc_hd__decap_12__ff_100C_1v65.lib.json
./skywater-pdk/libraries/sky130_fd_sc_hd/latest/cells/decap/sky130_fd_sc_hd__decap_12__ff_n40C_1v56.lib.json
./skywater-pdk/libraries/sky130_fd_sc_hd/latest/cells/decap/sky130_fd_sc_hd__decap_12__ss_n40C_1v60_ccsnoise.lib.json
./skywater-pdk/libraries/sky130_fd_sc_hd/latest/cells/decap/sky130_fd_sc_hd__decap_12__ff_n40C_1v95_ccsnoise.lib.json
./skywater-pdk/libraries/sky130_fd_sc_hd/latest/cells/decap/sky130_fd_sc_hd__decap_12__ss_n40C_1v28.lib.json
./skywater-pdk/libraries/sky130_fd_sc_hd/latest/cells/decap/sky130_fd_sc_hd__decap_12__ss_n40C_1v44.lib.json
./skywater-pdk/libraries/sky130_fd_sc_hd/latest/cells/decap/sky130_fd_sc_hd__decap_12.magic.lef
./skywater-pdk/libraries/sky130_fd_sc_hd/latest/cells/decap/sky130_fd_sc_hd__decap_12__ff_n40C_1v76.lib.json
./skywater-pdk/libraries/sky130_fd_sc_hd/latest/cells/decap/sky130_fd_sc_hd__decap_12.lef
./skywater-pdk/libraries/sky130_fd_sc_hd/latest/cells/decap/sky130_fd_sc_hd__decap_12__ss_100C_1v40.lib.json
./skywater-pdk/libraries/sky130_fd_sc_hd/latest/cells/decap/sky130_fd_sc_hd__decap_12__ss_100C_1v60.lib.json
./skywater-pdk/libraries/sky130_fd_sc_hd/latest/cells/decap/sky130_fd_sc_hd__decap_12__ff_100C_1v95.lib.json
./skywater-pdk/libraries/sky130_fd_sc_hd/latest/cells/decap/sky130_fd_sc_hd__decap_12.spice
t
It should have occurred to me that the checksums would be meaningless---the GDS file has a timestamp that's set according to the commit date of open_pdks, so any difference in the open_pdks version will result in a different GDS checksum.
g
Hi @User, were you able to resolve this issue in your design? If yes, could you share how?
h
@User I settled for a quick‘n‘dirty solution, which is that I made the digital block smaller, so increased the density and thus less 
decap_12
cells. Is also tried the 
_ef_
decap cells, but they caused issues with extraction, and I did not want to do a brute force approach of manipulating the final GDS and swapping cells.
👍 1
g
OK. Thanks for the prompt reply and feedback! Maybe I'll try that too and see if it resolves the issue.
Changing 
DIODE_INSERTION_STRATEGY
to 3 (from 4 that we were using) reduces the number of diode2 significantly. Could this be a solution? Is there a reason why 4 is used in the provided example?
h
I am not sure if a change to diode insertion will help. You should look at FILL and DECAP.
g
Thanks, I'll take a look at it.
13 Views
Open in Slack
PreviousNext
Powered by