At least one cell (sky130_fd_sc_hd__clkdlybuf4s15_1) violates SkyWater's own DRC rules and needs to be fixed.

[RTimothyEdwards]

The cell in question (sky130_fd_sc_hd__clkdlyabuf4s15_1) contains a poly overlap error (poly overlaps contact by 0.07um, where an overlap of 0.08um is required). There is no indication in the documentation that this rule can be waived, and there is no reason that the overlap can't just be extended to meet the rule. I does not compromise the standard cell circuit in any way.

The GDS of the cell needs to be fixed. Note that the above cell has two such errors in it.

I will fix the GDS and post the corrected version. If any other such examples come up, add them to this issue.

[RTimothyEdwards]

@mithro : Please substitute the following file for sky130_fd_sc_hd__clkdlybuf4s15_1.gds in the sky130_fd_sc_hd submodule. The zip file expands to the .gds file. This corrects the two DRC errors inside the cell. There is no indication in the SkyWater documentation that the existing DRC errors in this cell are either excepted or waiveable.

sky130_fd_sc_hd__clkdlybuf4s15_1_gds.zip

[tgingold]

I fear that clkdlybuf4s18_1 (and maybe clkdlybuf4s18_2) have a similar issue.

[RTimothyEdwards]

@tgingold : There are not very many of them, but it would be nice to get a complete list. Thanks for the heads-up.

[mithro]

@RTimothyEdwards -- Can we temporarily put them in a "Do not use, bad cell" list? (Like the one at https://github.com/RTimothyEdwards/open_pdks/pull/64 ?)

[RTimothyEdwards]

@mithro : How much harder is it to just apply my zip file and update the repository, than it is to add the cell to the "do not use" list and update another repository? I think there are few enough of these that I can just fix them as they are reported to me.

[ax3ghazy]

@mithro, @RTimothyEdwards: It is already on the list btw (https://github.com/RTimothyEdwards/open_pdks/blob/master/sky130/openlane/sky130_fd_sc_hd/no_synth.cells#L88). (doesn't mean the root cause shouldn't be fixed though).

[RTimothyEdwards]

@mithro : Note that being on the "no_synth" list does not prevent a cell from being used; it just prevents a cell from being used by the synthesis tools for synthesis. Any tool attempting to adjust timing of the clock tree would be expected to use these cells regardless of the "no_synth" status.

[RTimothyEdwards]

@mithro : This zip file corrects the GDS of the cell sky130_fd_sc_hd__clkdlybuf4s18_1.

I looked at the other cell mentioned (sky130_fd_sc_hd__clkdlybuf4s18_2) but it does not show any DRC errors. Seems to be limited to the two cells for which I have made corrected entries.

sky130_fd_sc_hd__clkdlybuf4s18_1_gds.zip

[antonblanchard]

I had a quick check of all the sky130_fd_sc_hd cells, and I could only find one additional cell that had a poly overlap issue. The full list:

sky130_fd_sc_hd__clkdlybuf4s15_1
sky130_fd_sc_hd__clkdlybuf4s18_1
sky130_fd_sc_hd__buf_16
sky130_fd_sc_hd__a2111oi_0

I did notice a few other DRC issues:

sky130_fd_sc_hd__probe_p_8:
Metal5 overlap of via4.< 0.12um (met5.3 - via4.4)

sky130_fd_sc_hd__tapvgnd_1:
Metal1 minimum area < 0.083um^2 (met1.6)

sky130_fd_sc_hd__tapvgnd2_1:
Metal1 minimum area < 0.083um^2 (met1.6)

[ax3ghazy]

@antonblanchard: Thanks! If you already haven't, It might be useful to add drc style drc(full) to your script (I am assuming you used one :-)) to reveal other potential issues detected by magic.

[RTimothyEdwards]

The first two of these layouts were corrected in pull request #2 to https://github.com/efabless/skywater-pdk-libs-sky130_fd_sc_hd fork, which automatically updates the upstream repos. Leave this issue open until all layouts have been corrected.

[antonblanchard]

@ax3ghazy I did run with drc(full). Here's the magic TCL script (does it cover everything?):

gds read $::env(GDS_FILE)
select top cell
drc euclidean on
drc style drc(full)
drc check
set drcresult [drc listall why]

set outfile [open "drc-errors.txt" a ]
puts $outfile $::env(GDS_FILE)

foreach {errtype coordlist} $drcresult {
	puts $outfile $errtype
}

close $outfile

exit

Run with:

for i in $(find . -name '*.gds'); do
        GDS_FILE=$i magic -noconsole -dnull -T pdk/sky130A/libs.tech/magic/sky130A.tech drc-test.tcl
done

@RTimothyEdwards do you want me to run the same test across the other libraries?

[mithro]

@ax3ghazy / @antonblanchard - We should set this up as an automated check to run on pull requests to this repository.

[antonblanchard]

I tested the hs cells and found:

sky130_fd_sc_hs__dlygate4sd3_1.gds
Diffusion contact to gate < 0.055um (licon.11)

sky130_fd_sc_hs__decap_8.gds
Diffusion contact to gate < 0.055um (licon.11)

[ramrajrl]

I tested the hs cells and found:

sky130_fd_sc_hs__dlygate4sd3_1.gds
Diffusion contact to gate < 0.055um (licon.11)

sky130_fd_sc_hs__decap_8.gds
Diffusion contact to gate < 0.055um (licon.11)

Do we have fixed GDS for HS Library cells as well? Thx

[jainsoumil2]

there's a drc issue with sky130_fd_sc_hd__buf_4 too -

Diffusion contact to gate < 0.055um (licon.11)Diffusion contact to gate < 0.055um (licon.11)

[RTimothyEdwards]

@jainsoumil2 : I do not know what you have done, but this is not an error. The presence of the area_sc identifier layer changes the DRC definitions to allow a diffusion contact to gate spacing of 0.05um. Given that you are showing contacts on the gate input and output, I'd guess that you flattened the circuit, destroying the standard cell identifier in the process, then read the result back from GDS. In that case, the circuit no longer identifies as a standard cell, and the DRC engine is correct in flagging the gate spacing as an error, but the standard cell layout itself is not in error.

[jainsoumil2]

Sorry, I have not flattened the design, please disregard the contacts in the screenshot. The buf_4 cell was an instance where the input and output gate contacts are placed one heirarchy above, for connections to other cells. I assume that should not destroy the area_sc identifier, am I missing something?

[RTimothyEdwards]

You're missing the area_sc identifier; I don't know how.