Running Magic's DRC Engine on the UART

In the previous article we looked at what design rules are and checked a couple by hand. In this article we run the real checker. The UART came out of Module 7 routed and timing clean, and that means nothing to a fab if the geometry underneath cannot be built. This is the first full lab of the module: Magic’s DRC engine, the full SKY130 rule deck, and the routed UART GDS that OpenLane produced.

Running Magic in batch mode

Magic is normally an interactive layout editor, but for DRC on a finished layout you want a scripted run that a CI job could call the same way you are about to. OpenLane’s own DRC step works like this, and the script below is a simplified version of the one it uses:

magic -dnull -noconsole \
      -rcfile "$PDK_ROOT/sky130A/libs.tech/magic/sky130A.magicrc" <<'EOF'
gds read runs/uart_full/results/final/gds/uart_top.gds
load uart_top
select top cell
drc euclidean on
drc style drc(full)
drc check
drc catchup
set oscale [cif scale out]
set fout [open drc_report.txt w]
set count 0
foreach {why boxes} [drc listall why] {
    puts $fout $why
    puts $fout "----------------------------------------"
    foreach b $boxes {
        puts $fout [format "%.3f %.3f %.3f %.3f" \
            [expr {$oscale * [lindex $b 0]}] [expr {$oscale * [lindex $b 1]}] \
            [expr {$oscale * [lindex $b 2]}] [expr {$oscale * [lindex $b 3]}]]
        incr count
    }
    puts $fout ""
}
puts $fout "COUNT: $count"
close $fout
quit -noprompt
EOF

It is worth understanding the script, not just copying it:

• -rcfile loads the SKY130 setup. Without it Magic does not know the layer stack or the rules.
• gds read reads the streamed GDSII, because GDS is what the fab receives and what you want checked.
• drc style drc(full) selects the complete rule set. Magic also has faster styles for interactive editing, which are meant for quick feedback while drawing, not for signoff.
• drc check starts the check, and drc catchup waits for it to finish. Magic’s DRC normally runs in the background as you edit.
• drc listall why returns every violation grouped by the reason, each with a list of boxes. The boxes come back in Magic’s internal units, so the script multiplies them by cif scale out to get microns, and writes everything to drc_report.txt.

Reading the report

For our UART, the report looks like this:

Metal1 spacing < 0.14um (met1.2)
----------------------------------------
88.050 55.900 88.190 56.100
91.410 62.230 91.520 62.410

Metal2 overlap of via1 < 0.055um (met2.4)
----------------------------------------
102.870 40.115 102.930 40.175

Local interconnect spacing < 0.17um (li.3)
----------------------------------------
45.230 102.415 45.400 102.585

COUNT: 4

The exact wording of each reason comes from the PDK’s Magic tech file and can differ a little between PDK releases. Each entry gives you three things, which I read in this order:

1. The rule, with its name in brackets (met1.2, met2.4, li.3). You can look the full rule up in the PDK documentation if the one-line reason is not enough.
2. The locations, one box per violation, in microns. Each box surrounds the offending geometry, and you can jump straight to it in Magic’s GUI.
3. How many times each rule is broken. A rule broken twice in one corner is a small fix. The same rule broken in forty places usually points to something systematic, such as a router setting or a cell that does not match the PDK version, and not to forty separate mistakes.

You might wonder why there are any violations at all, since the detailed router in Module 6 finished with zero. The router checks against the rules it can read from the technology LEF, which is a simplified subset of the full deck. Magic checks the complete deck, including rules the LEF cannot express. A few differences between the two are normal, and this is exactly why signoff DRC is run with an independent tool.

Summarising the report

On a design with more than a handful of violations you want a summary before touching any geometry. A short awk script counts the boxes under each rule:

awk '/\(.*\)$/ {rule=$0; next} /^[0-9]/ {n[rule]++} END {for (r in n) print n[r], r}' \
    drc_report.txt | sort -rn

2 Metal1 spacing < 0.14um (met1.2)
1 Metal2 overlap of via1 < 0.055um (met2.4)
1 Local interconnect spacing < 0.17um (li.3)

Four violations on a design of this size is a good result. The router and the rule deck mostly agreed, and what is left is a short, specific list.

If one rule had hundreds of violations, I would not fix them one by one. I would look for the cause, which is almost always upstream: a router setting, a cell footprint, or a PDK version mismatch. A few isolated single violations like these really are one-off geometry problems, worth fixing individually.

DRC is also not a one-time gate. Every time the layout changes after this point, an ECO, fill insertion or a manual fix, the full DRC check is run again, because any edit can introduce a new violation while fixing an old one.

Hands-on: confirm which rules actually ran

Before fixing anything, confirm which technology and rule style were loaded. If the tech file path is wrong, Magic can end up checking against something other than what you think, and you do not want to fix violations against the wrong deck.

magic -dnull -noconsole \
      -rcfile "$PDK_ROOT/sky130A/libs.tech/magic/sky130A.magicrc" <<'EOF'
puts "tech: [tech name]"
drc style
quit -noprompt
EOF

The technology should be sky130A and the list of DRC styles should include drc(full). If either is not what you expect, every report you read for the rest of this section is checking the wrong rules.

Practice Exercise

Given the summary above, which violation would you look at first, and why? Not the one that looks worst in the abstract, but the one most likely to tell you something about the routing that the others do not.

In the next article we take one of these violations and fix it: find it in the layout, adjust the geometry and run DRC again to confirm it is gone.