Added corrected GDS for five standard cells with known DRC errors #8
Conversation
…_16, clkdlybuf4s15_1, and clkdlybuf4s18_1) which are known to have incorrect layout that violates DRC rules (namely the poly surround distance for poly contacts). All violations are by a minimal 5nm distance, and all corrections are a trivial extension of the poly layer to meet the DRC requirement. All corrections lie within the existing layer boundaries and so pose no risk for interactions with other standard cells. These corrections have been in open_pdks as a patch to the skywater-pdk repository, and have been used in tapeouts.
|
This pull request fixes issue #261 (in the skywater-pdk issue tracker) |
|
Should we do a XOR imaging of the GDS to verify what are the affected blocks? |
|
@proppy : Or you can just trust that I know what I'm doing, because if we have to spend several days of back-and-forth messages over the verification of the contents of every pull request, then it will be several years before we finish correcting all the known errors in the PDK. |
|
Sorry if I phrased this poorly, I do trust your expertise, I was more after us documenting the changes happening to the layout themselves so that we're able to trace back (and potentially "replay" those) in case of an upstream update. I'll let @QuantamHD handle this. |
|
@proppy : In that case, yes, an XOR would be the appropriate (and probably only) method of confirmation. The only other method I can think of would be to use a tool that converts GDS to ASCII format and run a diff on the ASCII output. |
|
could a serie of magic commands to go from the upstream to the fixed version also be a way to document the change (and potentially make it reproducible?) |
|
I think we should merge this in, but an ASCII format for GDS sounds easy enough to build, and rather useful |
|
@proppy : I did not use magic to make the modification, so there is no set of magic commands that would fix the error. |
|
Generated this visual (and textual diff): by converting the gds to SVG before and after the change: (GitHub has some doc on how to visualize the diff here: https://github.blog/2014-10-06-svg-viewing-diffing/) For this shows that for
Hope that can help in case we want to document the precise change made to the geometries. |
|
@proppy : I think all layout should be in a human-readable format (CIF is good for that, too). But the diff-by-SVG seems to work fine. How did you get the text report of the difference? |
|
From here: |
|
@proppy @QuantamHD : Four days and counting and still this has not been merged. |
|
@RTimothyEdwards Still waiting on write access, but Proppy's visual diff also update the gds layout views? |
Gave it a try here: proppy@754a984 With the following command: This give a good overview of the changes:
Given that not all the files are affected in the same way (ex: no apparent
Does that means that we should store the file in
|
|
FYI - This change might conflict with some other work that Efabless wants us to do.... |
@mithro are those conflicting changes documented somewhere?
@RTimothyEdwards is that expected? |
|
@proppy : Yes, in some cells it was necessary to extend the poly, but in some cells there was sufficient space just to move the contact, which was a simpler fix. |
|
@RTimothyEdwards I tried to verify the DRC errors with the following script, I still some things are those unrelated to the fixes you're proposing here? sky130_fd_sc_hd__a2111o_1sky130_fd_sc_hd__a2111oi_0sky130_fd_sc_hd__buf_16sky130_fd_sc_hd__clkdlybuf4s15_1sky130_fd_sc_hd__clkdlybuf4s18_1 |
|
@proppy To get the difference between 2 GDS files, the best way to do that is using XOR. Any alternative method might not be as reliable. We have added this script that supports GDS to text records and text records to GDS and we have tried going to text and back and did an xor everything seems to be working great: |
Added corrected GDS for five standard cells (a2111o_1, a2111oi_0, buf_16, clkdlybuf4s15_1, and clkdlybuf4s18_1) which are known to have incorrect layout that violates DRC rules (namely the poly surround distance for poly contacts). All violations are by a minimal 5nm distance, and all corrections are a trivial extension of the poly layer to meet the DRC requirement. All corrections lie within the existing layer boundaries and so pose no risk for interactions with other standard cells. These corrections have been in open_pdks as a patch to the skywater-pdk repository, and have been used in tapeouts.