Why an Independent Second Tool Matters Here

Back in Module 1 I said that having both Magic and KLayout in the flow is not redundant. Now we can see why. Magic already checked this layout in Module 8 and wrote the GDS we have been looking at. So why run the same file through a completely different program? In this article I want to answer that, and then do it.

Two independent tools, not one tool twice

Magic’s DRC and KLayout’s DRC are separate programs: different code, different geometry algorithms, and rule decks written separately by different people from the same SKY130 design rules. A bug in how Magic implements one rule, an edge case in its geometric operations, or a rule transcribed wrongly into its tech file could all pass silently through Magic’s DRC. Running Magic again cannot catch a mistake Magic makes every time. A second, independently written tool reading the same GDS as raw geometry has a real chance of catching it. Figure 1 shows the arrangement.

Two independent DRC tools on the same GDS — Figure 1: The same GDS checked by Magic and by KLayout; agreement is a stronger result than either alone

The same idea is already built into OpenLane’s streamout, as we saw in Section 9.1: Magic and KLayout each write the GDS, and an XOR confirms the geometry is identical.

Running the independent check

The PDK ships KLayout DRC decks under libs.tech/klayout/drc. Run the main one in batch mode against the same GDS:

klayout -b -r $PDK_ROOT/sky130A/libs.tech/klayout/drc/sky130A_mr.drc \
        -rd input=runs/uart_full/results/final/gds/uart_top.gds \
        -rd topcell=uart_top \
        -rd report=uart_top_klayout_drc.lyrdb \
        -rd feol=true -rd beol=true

The deck name and its options vary between PDK releases; the comment block at the top of the deck lists what it accepts. The result is a report database you open in KLayout’s marker browser (Tools > Marker Browser), grouped by rule, with each violation clickable in the layout.

For the UART, after the fixes in Module 8, the report is empty in every category. That agreement is the real result of this article: not “zero violations” on its own, but two independently written tools, given the same geometry, both finding none.

When they disagree

Sometimes they will not agree. If KLayout flags something Magic did not, or the reverse, the right response is neither to trust KLayout automatically nor to dismiss it because Magic passed. Read the rule in both decks and in the SKY130 design rule documentation, and work out which implementation matches the documented rule. Open-source decks are maintained by people, and either one can lag behind or drift from the documentation.

In commercial work the foundry qualifies a specific signoff deck, and that deck’s result is what counts; teams sometimes run a second tool as well, but the qualified deck is the reference. With open PDKs no single deck carries that kind of foundry qualification, which makes cross-checking with two tools more valuable, not less.

Practice Exercise

Magic’s DRC on uart_top was clean. KLayout’s report is also clean, but it lists an informational note about a met4 slotting rule that Magic’s tech file does not check at all. What should you do, and why does the note alone already justify running the second tool?

Solution

Look up the met4 slotting rule in the SKY130 documentation and decide whether it is a real rule Magic’s tech file is missing, a coverage gap, or a check that does not apply to this design (for example because no met4 shape is wide enough to need slotting). If it is real and applies, it has to be checked and met, whichever tool reports it.

Either way, the note shows the value of a second tool. Running Magic’s DRC any number of times would never reveal a rule Magic does not implement. The note’s severity matters less than the fact that it exists.

With an independent geometric check and a look at the nets behind us, the next section brings every check from Modules 7 and 8 together into one explicit signoff checklist.