Reading a layer map

Someone hands you a chip drawing — a file from a colleague, or a cell you downloaded from a factory’s open design kit — and you want to answer a plain question: which of these shapes will become metal, and which are only notes for a program? Open the file in any editor and you will not find the word “metal” anywhere. You will find pairs of small numbers. The table that turns those numbers back into meaning is the factory’s layer map, and reading it one row at a time is one of the most useful habits in layout.

This is a small teaching neighborhood drawn in LayoutEditor with the layer numbers of the open SkyWater 130 nm process, usually called sky130. On the left sit two transistors the size of one inverter: green diffusion, a red polysilicon gate, purple local interconnect, black contact squares. Blue metal1 rails run along the top and bottom. A blue metal1 wire carries the output to the right, where an orange metal2 strap lands on it through one small red via. Each tag names a shape the way the factory’s table does: number pair first, then the layer name, then the purpose. Now look only at the right half. The wire, the dark hatched rectangle at its end, the letter Y, and the tiny via square all begin with 68. One number, four different jobs. The tags are annotation added for this article; the letter Y and the words VPWR and VGND are real labels stored in the file.

A file full of numbers

The common exchange format for chip layouts, GDSII (often shortened to GDS; see GDSII in plain language), stores every polygon with two integers: a layer number and a datatype. A piece of text gets a layer number and a texttype. The file holds no names and no colors; the colors on your screen are your editor’s habit. What the two integers are is the subject of GDS layer and datatype. This note is about the next step: decoding them.

Why numbers instead of names? The format grew out of Calma’s Graphic Data System in the 1970s. Its 1979 product specification offered 64 layers and 64 datatypes per layer, and it described the datatype as a way to classify shapes inside one layer. Its own example puts metal on layer six and marks the supply connections as layer six, datatype one, so they can be selected and viewed separately. Modern kits do the same with more rigor. Numbers are small and read identically by every program; names are local and drift. So the meaning lives outside the file, in a table the factory publishes with its process design kit, or PDK — see what a PDK actually contains.

Reading one row

Here are four rows from the sky130 layer table, as the kit documents them:

Layer	Purpose	GDS layer:datatype	Description
met1	drawing	68:20	Metal 1
met1	pin	68:16	text and data
met1	label	68:5	text type
via	drawing	68:44	Contact from metal 1 to metal 2

Read each row from left to right. The name tells you which film or process step the shape belongs to: metal1, the first wiring level. The purpose tells you what the shape is for. The pair is what actually sits in the file. The description is where kits hide the small print, including which kind of object the row accepts. “Text type” means the row is for text: the 5 is a texttype, so a polygon that ends up on 68/5 is not a label at all — it is a stray shape nobody will read.

In sky130 the first number groups a neighborhood of the process (66 for poly and its contacts, 67 for local interconnect, 68 for metal1, 69 for metal2) and the second number names the job: 20 for drawn shapes, 16 for pins, 5 for labels, 44 for the cut that sits on top. Not every kit is this tidy. You read the table, not the pattern.

What the purposes mean

Drawing is the purpose that becomes material. A 68/20 rectangle is metal on the finished wafer.

Pin marks where a connection to this cell is allowed. Routing programs and circuit checkers use it to find a cell’s terminals, and the sky130 rules expect a pin shape to sit inside drawn metal of the same level. It adds no metal. A pin rectangle with nothing drawn underneath it describes a terminal made of air.

Label is text that names a net — here Y, VPWR, and VGND. Layout versus schematic checking (LVS), the step that asks whether the drawing is still the intended circuit, reads those names to match the drawing to the schematic. More on text in text on a layout.

Cut rows, like the via at 68/44, share the metal’s first number but describe a hole through the insulator to the next level. They get their own photomask (vias and contacts).

Blockage rows (sky130 lists metal1 blockage at 68/10) tell a place-and-route program to keep its wires out of an area. They are never manufactured. Fill or dummy rows are the opposite: extra metal that is manufactured so the wafer polishes evenly (density rules and fill). Boundary and identifier rows, such as sky130’s cell boundary at 235/4 or its standard-cell marker at 81/4, are notes for programs and never reach a mask.

These are the same LayoutEditor cell with different rows lit and the rest faded. Top left: only 68/20 drawing — the rails and the output wire, the metal a factory will actually deposit on that level. Top right: only the pin and label rows — one hatched pin rectangle at the end of the wire and three net names; none of it becomes metal. Bottom left: only the cut rows — the black contacts on 66/44 and 67/44 and the red via on 68/44. Bottom right: what a reader that ignores the datatype makes of the 68 family. Pin, via, and wire collapse onto one sheet, the via square and the pin vanish into the blue, and nothing on the screen warns you.

From a row to a mask

A drawn row is not automatically a mask. A photomask is a glass plate the factory makes for one patterning step, and the factory’s software builds its data from your drawn rows, sometimes adding shapes of its own. The sky130 table keeps a separate block of mask-level rows for exactly this reason: the metal 1 mask appears as its own entry, built by the factory’s software from what you draw on 68/20. The GF180MCU design manual has a mask table with columns for mask number, “drawn” or “generated,” polarity, and output layer. Its Metal1 row reads mask number 80, drawn plus generated, output GDS layer 34. Some masks there have no drawn row at all; the factory generates them. Pin, label, blockage, and identifier rows make no mask of their own.

So reading a row includes one more question: does this become chrome on glass? If the layer table does not say, the design manual does.

Same words, different numbers

The vocabulary repeats from kit to kit; the numbers do not. In the IHP SG13G2 process, metal1 drawing is 8/0, its pin is 8/2, and its text row is 8/25, described as “used for LVS.” In GF180MCU, metal1 is 34/0, its label 34/10, its dummy fill 34/4, and a place-and-route blockage 34/5. Sky130 says 68/20. A generic photonic kit puts the silicon waveguide core on 1/0, marks optical ports on 1/10, and uses 68/0 for a device outline. A number pair is meaningless until you know which kit it came from. What happens when you open a file with the wrong kit’s map is the cautionary picture in what a PDK actually contains.

Other fields show the same idea in other clothes. Circuit boards rarely tag shapes with numbers; each layer travels as its own file, and modern Gerber files carry an attribute such as “Copper, L1, Top,” so the board’s map is the stackup plus those file labels. Micro-machined (MEMS) processes usually publish a short table per process in a design handbook (MEMS is layout plus a recipe).

A common mix-up

Beginners read the colors as the map. They are not; two editors can paint 68/20 blue and green and both be right. Close behind come treating a pin as extra metal, assuming every row becomes a mask, and trusting a name: “met1” in one kit and “Metal1” in another share a word and nothing else.

Things that go wrong

Datatypes get merged. Some import settings put every datatype of a layer number onto one sheet. In sky130 that turns every via into metal1 and every pin into an anonymous rectangle (the bottom-right panel above).

Labels land on the wrong purpose. A net name typed on the drawing row instead of the label row may be legal in one kit and invisible to the checker in another. LVS then reports unnamed nets on a wire that is plainly labeled on screen.

A routed design is converted without the map. Digital flows hand over placed-and-routed designs in DEF, the design exchange format, which names layers by name, plus LEF, the library exchange format that describes the cells and the wiring stack. Turning that into GDS needs a map file with lines such as met1 NET,SPNET,VIA 68 20, met1 PIN,LEFPIN 68 16, and NAME met1/PIN 68 5. Without one, a converter has to invent numbers — KLayout’s documentation for its LEF/DEF reader describes how it falls back to numbering layers by their position or by name order.

Two maps disagree. Community map files for the same open process give the via pin different datatypes, and both look official. Use the map that ships with the kit, and note its version.

A good check costs a minute: open one standard cell from the kit, confirm that its output pin sits on the pin row and its net name on the label row, and only then trust your own files.

In software

LayoutEditor keeps the numbers of a GDS file untouched by default, so what you see is what the file contains. When you want names, it can map each layer/datatype pair to its own named LayoutEditor layer on load and save. Then 68/20, 68/16, 68/5, and 68/44 arrive on four layers instead of piling onto one. The mapping is set in the setup dialog or by a macro; the figures in this note were drawn that way, and the saved file contained exactly the sky130 pairs.

This is the LayoutEditor window after the map is set up and the saved file is opened again. The layer panel on the left reads like the kit’s table — nwell 64/20 through met2 drawing 69/20, with met1 drawing, pin, and label as three separate entries — and each can be shown, hidden, or recolored on its own. The drawing is the same cell as above, rebuilt from nothing but numbers in the file.

The Layer Manager can import a Cadence-style layer table (names with their numbers) and a display file with colors and fill patterns, and it can load both automatically from the working folder. Visibility can be switched per datatype. GDS has no place for layer names, so LayoutEditor offers an optional, non-standard way to store them in a hidden cell; OASIS, the newer exchange format, can carry layer names in the file itself. The sky130 setup for LayoutEditor runs a short macro before any design is loaded that maps wires and vias sharing one layer number onto separate layers — the 68 problem from the first picture, solved once at startup. Other tools follow the same pattern with their own files: layer tables in Cadence-style flows, layer-property files for display in KLayout, and dedicated map files for LEF/DEF conversion.

Whatever the tool, the reading stays the same: find the pair, name the step, say the purpose, ask whether it becomes a mask, and read the description column for the rule hiding there.