https://open-source-silicon.dev logo
Join Slack
Powered by
I'm seeing a difference between the DRC count in M...
# magic
b
I'm seeing a difference between the DRC count in Magic using my project's top level .mag file (and live/interactive 
drc(full)
), and the count in Magic from rendering the generated GDS. From the .mag file, there are no errors. There are over 1,000 errors unique to the imported GDS, which seem to mostly boil down to layers overlapping, especially the generated MCONs. It seems like the areas with problems are isolated to where certain combinations of connections (such as m2contact and viali) overlap. Is it safe to ignore these DRC errors as spurious? Or is there more to it? For reference, my latest layout/GDS can be found here: https://github.com/b-etz/sky130_be_ip__lsxo
t
Importing designs into magic from GDS can be problematic due to Magic's habit of creating lots of derived layer types. Usually to get a clean DRC after reading GDS requires some amount of flattening; I will take a look and advise you how to read it to get a clean DRC.
Never mind, that doesn't apply here. The issue is that there are already 
mcon
contacts (local interconnect to metal 1) in the parameterized FET cell. There are also 
mcon
contacts placed on top of these in the top level layout. What I don't understand is why this isn't flagged as an error in the .mag file; it should still be claiming that the layers "can't abut or partially overlap". There should also have been an error message when you wrote GDS about "parent and child disagree on CIF". . . but there isn't. I will have to figure out why those errors don't show up until you write out GDS and read it back in again. I would suggest doing 
see no * ; see mcon
, which makes it easier to see where the 
mcon
contact layers are overlapping, and then modifying those generated cells to avoid creating the contacts to metal1, since you already have those in your top level.
b
I have seen DRC errors in Magic when a layer like locali partially overlaps a p-cell layer. But if it completely overlaps a layer, the DRC error clears.
t
Somehow I feel that that was a major oversight in the DRC code. . . and am surprised that it escaped my notice.
b
It seems reasonable to me. I would think the rectangle of greatest area out of a set of overlapping rectangles should be written to GDS. Unless I'm missing something
t
You're missing the fact that the overlap happens between parent and child cells. The parent cell and the child cell are written independently. In principle, the parent cell could compensate for what's already in the child cell, but magic's code doesn't do that.
b
So, as I understand it, the attached snip shows a region with child cell mcon underneath parent cell mcon. This is definitely a situation where the DRC error cleared after I fully overlapped the child cell mcon. Is there a way for me to flatten all layers into the top level before writing GDS? Would that be the fastest way to generate DRC-clean GDS?
t
Flattening layout is kind of frowned upon. The better choices: (1) Assume that you already have as many contacts as will fit in that area and replace the mcon with local interconnect + metal1 in those areas; (2) just bring up the parameter window for the underlying device, and uncheck the box that draws the mcon over the transistor source or drain.
Yes, flattening is faster. But do try to refrain from taking drastic measures. . .
b
Understood. Thank you for the guidance!
Oof. As a side-note, erasing mcon also erases attached li and m1. Bothersome but manageable.
t
@Brady Etz: Use the command 
contact erase mcon
.
👍 1
3 Views
Open in Slack
PreviousNext
Powered by