I have some very basic questions about the routing rules for sky130, for example: 1. What should I assume in terms of what standard cells and other macros will be using, in terms of met1 through met5. Like, should I always assume that met3, met4, and met5 are available for routing, or when might other folks be using various layers in various ways? 2. Are the constraints on the metal layers being north/south vs east/west intrinsic to manfacturing, or is that just a convention? 3. What are all of the fine details of the routing rules? I don't just mean antenna check stuff, but, like how close can traces be, how big are the traces, how big are vias, and what is allowed underneath a via between metal layers 4 and 5, for example? Like, can I have overlapping vias between 2 and 3, and 4 and 5? Is there some easy way to find all of this information? In particular, I'd like to know for doing some hand layout.

A good place to start might be the

$PDK_ROOT/$PDK/libs.ref/*/techlef/*/tlef

files.

1) standard cells for sky130 primarily use only Li and m1 for internal routing. Some cells can use m2 but sparingly. This is generally true for all PDKs. Macros don't have any hard rules. The convention might be to use up to either m3 or m4 in most cases. You can find different layer usage depending on whether the block uses a power mesh or power ring. 2) for sky130 it is convention. For more advanced nodes (circa <20nm) it is basically required. Manhattan routing, as it's called, allows for higher capacity for routes than if it is not used. In more advanced technologies, "wrong-way routing" has stricter rules and eventually gets to the point that it doesn't make sense in most cases to do anything but Manhattan routing. Wrong-way routing is much more common in full-custom layout rather than cell-based/automated layout. 3) I think most details are covered in the docs https://skywater-pdk.readthedocs.io/en/main/rules/assumptions.html

@Austin Rovinski Very helpful, thank you! That page is fantastic. I'll probably have a few more questions as I implement routing, but this is a great starting point.

If you're looking for an off-the-shelf solution, OpenROAD has a global and detailed router which already understands all the sky130 rules via the tech LEF.

@Austin Rovinski Thanks, however my goal is to implement these things myself. But comparing to OpenROAD might be pretty helpful, is it easy to describe what the interface is for OpenROAD to request it route things? Like, can I literally just say "please connect up these rects on these layers into these groups, and here are rects of all of the obstructions on various layers"? Or is the interface pretty complicated?

The interface is that you need a LEF abstract representing your cells so that it knows where the pins are, and it needs a verilog (or DEF) netlist to map all the connections between pins. OpenROAD understands basically anything in LEF/DEF format: layers, preferred routing directions, DRC rules, existing metals and obstructions, etc. If you don't have LEF abstracts of your cells, I believe Magic has a LEF abstractor built into it that you could try. If your layout is not cell-based, then it might be difficult to import it to OpenROAD, because that is how the importing currently works.