Hi <@U01680FK487> After my design went through the...
# openlane
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.
This are examples of a vias error and a spacing error.
We also see spacing issues between macro blockages/SRAMs and surrounding routes like this:
Left is obsm2 and right is m2
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.
Should that be an openlane or tritonrouter bug then? Is there a way to specify wide metal spacing to the router?
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.
👍 2
@Tim Edwards I'll file something
It's also technically not flagged as a "DRC" error because it involves obs layers, it seems. It is marked as an "error" though. Which is kind of confusing...
As flagged by which tool?
If you load the def/lef, it says no DRC errors. If you run "drc count" it shows no errors. If you run "drc find" it starts taking you to the errors. It's not a catch-up issue either
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.
I'm using the standard .magicrc from sky130A
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?
Copy code
: drc count
Cell dff_buf has just one error tile.
Total DRC errors found: 0
: drc why
N-well spacing < 1.27um (nwell.2a)
That has no LEFs
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.
@Tim Edwards Why does drc listall count total not actually output to stdout or stderr? If I run it interactively, I see the result, but if I run it in a script with -dnull -noconsole I just get... nothing.
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.
@Tim Edwards can you clarify a little more what the drc listall option does? It returns a list of cells with counts which are presumably DRC errors inside those cells? In the SRAM, some of these may be DRC incorrect (even when reduced to a maglef) until they are tiled together.
so it kind of does two things, the hierarchical errors in all cells as well as considering errors with obstructions? I want the later but not the former