Hi @User After my design went through the tool flow. I load the def and lef file in magic and ran its DRC checking. It is showing design has “22900 DRC Error Tiles”(the number is indetermistic) and 0 DRC error. Most of them are “Metal3 minimum area < 0.24um^2”, “Metal3 minimum area < 0.24um^2” and “Metal > 3um spacing to unrelated m3 < 0.4um”. I will attach some screenshots in the thread.

We also see spacing issues between macro blockages/SRAMs and surrounding routes like this:

I think @Tim Edwards can explain this

@Yuanpeng Liao : Just looking at the layouts, it's hard to see what is going on. In the first picture, I'd have to see the layout restricted to via2 and metal3 only to see where the error is. In the second picture, I don't know what is the actual distance between the line and the area to the right. @Manar Abdelatty: Not really. What Matt is showing, and what might also be the error in Yuanpeng's 2nd picture, is a failure of the router (TritonRoute, I assume) to satisfy the wide-width spacing rule when routing a wire close to a large obstruction area. It has always been my assumption to treat obstructions like a metal layer, and apply all metal rules to them. But from the results, I'm under the impression that TritonRoute does not do this. It seems to only apply the base metal spacing rule between a wire and an obstruction of any size.

@Tim Edwards Yes, that is what I'm thinking with the second of @Yuanpeng Liao and my photo.

The wide spacing rule is in the technology LEF file, so TritonRoute should know about it. My gut feeling is that it is really an interpretation of how the rule should be applied with respect to obstruction layers. But it's also possible that TritonRoute just ignores wide spacing rules.

@Tim Edwards I'll file something

As flagged by which tool?

Magic.

It is flagged as a DRC error, but there is apparently a mismatch between what gets returned by "drc count" vs. "drc find". This might have to do with the LEF view being marked with abstract. I remember you mentioning this before but I have had so many fires to put out, I haven't had the time to look at it closely.

@Tim Edwards I see some similar behavior just opening cell layouts in .mag format. It will say that DRC is clean, but if I do :drc check it then shows errors.

It's easy to get this behavior because magic believes what's in the .mag file. If the .mag file doesn't declare any DRC check areas, then when loading the file, magic assumes the design has already been checked and reports clean.

Why this after forcing a check then?

: drc count
Cell dff_buf has just one error tile.
Total DRC errors found: 0
: drc why
N-well spacing < 1.27um (nwell.2a)

I think that's mostly because I added various behavior to the "drc count" command to get it to do what I wanted under various situations. . . There's "drc count", "drc count total", "drc list count", "drc list count total", "drc listall count", and "drc listall count total". Feel free to harsh on me for making that mess. . .

Ok, so drc listall count total should be more comprehensive. I'll update my scripts to use that result instead of just drc count.

Because I use "list" or "listall" to indicate that the result should be set as a Tcl result. The interactive Tcl session prints all results. To get that from a script, you need to do, e.g.,

puts stdout [drc listall count]

. It is intended to be used in a script to set a value to the result and then do further processing on that variable (

set results [drc listall count]

).

Got it. Thank you.