Standard-Cell ASIC Physical Design: Netlist to GDSII

Welcome. This is the first lesson in a course that will take you from the physical-design flow to the timing, routing, signoff, and project work expected in a fresher role. Today, the goal is to build a reliable map of the flow: what a physical-design engineer receives, what changes at each stage, and what must be checked before a layout is handed off. We will follow a small standard-cell block from its synthesized netlist to GDSII.

---

The starting point: a circuit without locations

Imagine a synthesized block containing a launching flip-flop, an AND gate, and a capturing flip-flop. Its gate-level netlist identifies the cell instances and their connections. It might say that the launching flip-flop’s output drives an AND-gate input, and that the AND gate drives the capturing flip-flop’s data input. It does not say where those cells sit on silicon or which metal wires connect them.

Physical implementation supplies that missing geometry while trying to satisfy constraints. The tool also needs information beyond the netlist: timing constraints, cell timing and physical views, and technology data describing the available layers and rules. We will examine those files individually in the next lesson; for now, distinguish the circuit to be implemented from the information needed to implement it.

Watch this short overview for the visual progression from inputs to placed cells, clock distribution, and wires:

The supplied flowchart is a useful map of the fuller journey:

Read the chart as a sequence of design states, not as a promise that every company runs exactly these commands once. Checks may reveal a problem that sends an engineer back to an earlier state. Optimization appears more than once because a fix made before wires exist may need revisiting after real wires—or a real clock tree—change the timing.

---

Establishing a physical plan

Design initialization loads the circuit and its supporting data into a physical-design tool. An early sanity check asks whether the inputs are coherent: for example, can the tool find a physical and timing definition for every cell named in the netlist? Do the clocks and constraints refer to the intended design? Proceeding with a missing cell or an incorrect clock can make every later result misleading.

Floorplanning then establishes the block’s die and core boundaries and creates rows where standard cells may be placed. It considers where external pins should sit and reserves space for wiring. If the block contains hard macros, such as SRAMs, their locations and the routing space around them need attention here; a simple standard-cell-only block may have none. Power planning creates a distribution network so cells can receive power and ground. Depending on the technology and flow, this stage also includes physical-only cells such as tap or endcap cells.

The distinction between floorplanning and placement matters. After floorplanning, we know where cells are allowed to go, but most logic cells do not yet have final locations. In our example, we can define rows and locate the block’s input and output pins without yet deciding which row contains the AND gate.

The chart’s pre-placement box collects preparations that vary by flow, such as inserting required physical cells and setting placement restrictions. Its repeated sanity-check boxes are reminders to verify the state before committing to the next expensive operation. The precise division between floorplan and pre-placement work is less important than knowing that the movable standard cells must enter placement with valid rows, usable power, and space to connect their pins.

---

From placed cells to routed connections

Placement assigns locations to the standard cells in the netlist. A placement tool considers connection lengths, timing, available space, and likely routing congestion. Legalization ensures cells occupy valid row positions without overlapping. In our example, the two flip-flops and AND gate now have coordinates—but their signal connection may still be an estimate rather than a finished metal wire.

That is why pre-CTS optimization uses estimates. The tool can resize a gate or insert a buffer to address a timing or electrical problem, but it does not yet know the final delay of every routed wire. It must also leave a placement that can actually be routed. A timing improvement that packs too many cells and connections into one region can create trouble later.

The clock deserves its own implementation stage. A clock input may have to reach hundreds or thousands of sequential-cell clock pins. Clock-tree synthesis (CTS) builds and places a distribution network, commonly using clock buffers, to reach the intended sinks while controlling clock arrival differences and signal quality. Before CTS, timing analysis generally relies on an ideal or estimated clock network; afterwards, the implemented network changes when clock edges reach the flip-flops. That can change both setup and hold results, so post-CTS optimization checks and repairs the design again. Later modules will show how to interpret those timing changes rather than merely naming them.

Routing turns connections into metal shapes and vias between layers. Global routing plans where connections can travel and helps expose congestion. Detailed routing assigns tracks, shapes, and vias while working within manufacturing rules. In our example, the AND gate’s output-to-flip-flop connection becomes a physical route, not just a line in a connectivity list. A completed route also needs working clock, signal, and power connectivity; “the router finished” is not by itself a signoff result.

With routed geometry available, the tool can estimate interconnect resistance and capacitance much more accurately. Post-route optimization may adjust cells or routes to repair timing and electrical problems. Any such change has consequences: adding a buffer changes placement and connections; moving a wire may affect a design rule or another path. This is why checking continues after routing rather than stopping when the wires first appear.

---

Following the design through its saved states

In practice, engineers do not rely on memory or a single final picture. They save intermediate design states and inspect logs and reports to see what changed. The OpenROAD Flow Scripts tutorial gives a concrete example. Its filenames belong to that example flow, not to every tool, but the organization illustrates what to look for in any implementation run.

The example saves a synthesized Verilog netlist, floorplan and placement states, a CTS state, a routed state, and final outputs. Its .odb files are implementation databases used by that flow; other tools have their own checkpoint formats. A .def file can also represent physical placement and routing information. The final .gds is different in purpose: it represents layout geometry for handoff. A .spef records extracted interconnect parasitics for timing analysis; it is not a drawing of the layout.

A useful way to trace a run is to ask two questions at each checkpoint: What physical information exists now that did not exist before? and What evidence says this state is acceptable to build upon? Placement gives cell locations, for instance, but a placement report is still needed to judge congestion and timing. Detailed routing gives wire geometry, but route completion and violation reports are needed to judge it.

---

Signoff makes the handoff defensible

The physical-design flow does not end merely because a GDSII file can be written. Signoff checks the implemented design against its electrical, logical, and manufacturing requirements. Read the introductions to three central checks in OpenLane’s newcomer documentation:

These checks answer different questions. Design-rule checking (DRC) asks whether the layout obeys applicable geometric manufacturing rules. Layout-versus-schematic (LVS) asks whether connectivity extracted from the layout matches the intended circuit. Static timing analysis (STA) asks whether constrained paths meet their timing requirements using appropriate cell and interconnect delays. A timing pass does not establish that the circuit’s intended function was correct; functional verification addresses that separately. A routed design may also require checks such as antenna and power-integrity verification.

Finally, the verified layout is prepared for GDSII handoff, often called stream-out. The layout must include the relevant cell geometry as well as the block’s placed and routed geometry. OASIS is another layout-exchange format you may encounter. Neither file is a manufactured chip, and the layout file alone does not communicate every assumption behind signoff. A responsible handoff identifies the final design state and accompanies it with the required verification results and supporting deliverables for the receiving team or foundry flow.

For an interview, the concise distinction is this: synthesis produces a connected cell-level circuit; physical design gives it legal locations, power, clocks, and wires; signoff checks the implemented layout; GDSII or OASIS carries the layout onward. The repeated checks and optimizations are part of that flow, not optional decoration around it.

---

Key takeaways

You can now trace what is added to the design at each major stage: a floorplan provides physical boundaries and resources; placement locates cells; CTS implements clock distribution; routing implements interconnect; post-route work refines the result; signoff checks whether it is ready for handoff. A saved checkpoint or a generated GDSII file marks progress, but neither substitutes for checking the state it represents.

Next, we will open up the input side of this map and identify exactly what the netlist, SDC, Liberty library, technology file, and parasitic file contribute.