-
Notifications
You must be signed in to change notification settings - Fork 69
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
Solve poly density issues #558
Comments
I have created new fill cells for the sky130_fd_sc_hd library. I copied the sky130_ef_sc_hd__decap_12 cell and created cells with 80%, 60%, 40%, and 20% poly density of the original cell (the original cell is normalized to 100%). Along with the existing newfill_12 cell, we're covered from 0% - 100% density. I also created a sky130_ef_sc_hd__fill_2 cell. We now have sky130_ef_sc_hd__fill_8, sky130_ef_sc_hd__fill_4, sky130_ef_sc_hd__fill_2 cells which match the width of the sky130_fd_sc_hd__fill_8, _4, and _2 cells. The difference being the ef fill cells have diffusion in them. We can leave the sky130_fd_sc_hd__fill.... cells in the library but recommend our customers avoid them due to likely FOM density issues. I don't think the fill algorithm will place FOM fill shapes in the fd fill cells because the nwell height and space are too short, and maybe not place P1M fill shapes either. There is a sky130_ef_sc_hd__fill_12 cell in the library that I recommend we also recommend our customers avoid. It causes nwell spacing issues when PNRed. You can see the different cells in I ran experiments with the different cells on an 11 sample set of the 2411 chips. These included a wide spread of decap_12 cell counts (290k - +500k). All the chips in the test passed poly density with approximately 6.5% margin. These results are also in the above Sheet link. Three things need to happen to complete this ticket.
|
@DavidRLindley : Please send me the GDS for these cells (and any other views, if you happen to have any, although I can work with just the GDS), and I will incorporate them into open_pdks. The I have a |
Sent via Slack.
…On Fri, Dec 6, 2024 at 10:53 AM R. Timothy Edwards ***@***.***> wrote:
@DavidRLindley <https://github.com/DavidRLindley> : Please send me the
GDS for these cells (and any other views, if you happen to have any,
although I can work with just the GDS), and I will incorporate them into
open_pdks.
The sky130_ef_sc_hd__fill_12 could be modified to avoid the nwell error,
but it is actually a decap cell and should not be listed as a fill cell. I
could generate a new fill_12 cell that is, effectively, a fill_8 abutted
to a fill_4 (that is, not a decap).
I have a newfill_12 cell as well, which is one we used previously to work
around density issues. Is that now deprecated?
—
Reply to this email directly, view it on GitHub
<#558 (comment)>,
or unsubscribe
<https://github.com/notifications/unsubscribe-auth/BFSQ4KNYNGET7A2CG7E2FF32EHB7LAVCNFSM6AAAAABTDNQ3OKVHI2DSMVQWIX3LMV43OSLTON2WKQ3PNVWWK3TUHMZDKMRTGU2TEOBVGI>
.
You are receiving this because you were mentioned.Message ID:
***@***.***>
|
Sorry, @RTimothyEdwards, I didn't fully read your message. The sky130_ef_sc_hd__newfill_12 cell should be replace the sky130_ef_sc_hd__fill_12 cell. |
Many chips on 2409 and 2411 where flagged for poly density exceeding the max limit. This is caused by the OpenLane configuration prioritizing the sky130_ef_sc_hd__decap_12 for fill. This cell has too much poly (10.8um^2 per cell). For 2409 and 2411 these poly density errors was corrected post tapeout flow. This should be pushed back to the designer. The solution is to create a set of decap_12 cells with different poly densities. I suggest modifying the decap_12 cell because that will
The text was updated successfully, but these errors were encountered: