<@U016EM8L91B> <@U017X0NM2E7> Hi, I failed prechec...
# magic
l
@Tim Edwards @Mitch Bailey Hi, I failed precheck on the klayout_feol_check where there are two min psd spacing errors. The weird thing is this DRC error is located in my puf_super block that I generated using the commercial digital flow (innovus place and route). I checked the klayout mr rule deck on this block alone and it passed klayout DRC. Then, after I integrated this block into the user_analog_project_wrapper and ran precheck locally did this DRC pop up. Can you help me debug this? Thank you. Here is the git repo for my user_project: https://github.com/lsammarone/OpenPUF
m
@Luke Sammarone psdm/nsdm width rules were missing from mpw-3 tech files. What's the date on your local klayout mr rule deck? Does it have a psdm width rule?
l
#  History :
#   2022-2-17 : 2022.2.17_01.04 release
@Mitch Bailey Both mr rule decks (in my user project repo and my digital flow repo) have the same date at the top. I diff'd the two and they are the same:
m
Do they have a
min. psdm width
rule?
t
@Luke Sammarone: I'm not exactly sure how the flow goes when you drop in something created by Innovus. But the above error looks like the kind of patch applied by magic to work around DRC issues, in this case, two areas of PSDM that are too close to each other in a catecorner arrangement. There are multiple things going on here, so I'll try to break it down: (1) It appears that magic might have a round-off issue, because it was trying to ensure PSDM minimum width and apparently just missed it by a tiny bit. I will need to review the geometry here and figure out where the round-off error occurs; it should be something pretty easy to fix in magic. However, (2) if you can assume that Innovus generates correct GDS, then you can turn off this "patching" behavior with the command
cif *hier write disable
in magic. But normally if the layout is DRC correct to begin with, then magic shouldn't be trying to patch it. That leads me to believe that (3) you have Innovus set up in such a way that it is not adding fill or decap cells between the logic gates. Otherwise, the logic gates are designed to have continuous NSDM and PSDM across the width of the standard cell so that you won't get catecorner shapes like that.
@Luke Sammarone: I'm also wondering if this could be a false-positive klayout DRC error. I can't make magic generate a bridging shape in NSDM or PSDM that is less than 0.38um high (which is the NSDM and PSDM minimum width rule). What is the actual measurement of the length (in klayout) of the line between the inside corners of PSDM, representing the minimum width of the shape?
l
OK so (3) is definitely not happening, innovus is adding fill/decap and i can see them in the gds:
t
@Luke Sammarone: Okay, then, the issue has to be that you (or the build process) have read the Innovus-generated layout directly into magic without treating it as a "read-only" block (which ensures that all of its contents are copied to the final layout verbatim from the Innovus GDS source), so that magic ends up writing out its own version of the standard cells (with certain layers like NSDM and PSDM ignored on input and regenerated automatically on output). This would normally be okay and produce valid layout except for whatever round-off error is going on; but generally, you don't want magic altering your user project GDS. But I don't know where in the process that happened. The "make ship" (or "make truck") process is clearly marking the user project cell as read-only GDS so that magic won't mess with it.
l
The measurement is 0.01 of that line between the corners on the bottom. On the top corner, there doesn't seem to be a line width that is less than 0.38 (0.395um).
In the gds read there is a "readonly" option, let me try this. I do read in the gds into magic when I integrate into the user project, so this might be it.
t
@Luke Sammarone: This would be the measurement in question that klayout is flagging. It looks like it might actually be slightly less than 0.38um. I'm still trying to figure out if I can reproduce that error in magic (even though your best solution would be to address the underlying cause and therefore avoid the actual DRC error altogether). What is the cell that is directly below and to the right of the error? it looks like a buffer size 1 but I can't match it to a specific standard cell layout.
l
Hi @Tim Edwards I made the puf_super digital block readonly and now I pass Klayout FEOL check. But, I am not passing Magic DRC in precheck (new error). Here is the new psdm geometry in the original offending area: Below and to the right of the psdm error is a sky130_fd_sc_hd__tapvpwrvgnd_1 and a sky130_fd_sc_hd__dfrtp_2
t
@Luke Sammarone: Very interesting. That specific pair of cells does produce the width error, so that gives me something to research in magic's code base. The magic DRC in precheck will not cause a project rejection, but let me know what it is if you're concerned about it.
l
@Tim Edwards I passed Magic DRC (some issue where i deleted a via on accident) and Klayout FEOL, thank you for the help!
t
Thanks, and it was very helpful to uncover that error, which I need to go fix sometime.