From RTL to Silicon

The Digital Design and Verilog course ended when a design simulated correctly. This course starts there.

Your testbench has gone green. Every assertion passes, every corner case you thought to write is covered, and coverage is at whatever number the team agreed was enough. By every measure the RTL course taught, the design is done. It is not a chip, and it is not close to one. What you have is a precise, simulatable description of behaviour: a promise that if you clock this thing correctly and feed it these inputs, it produces those outputs. Nowhere in it is a size, a shape, a wire length, a power grid, or any physical fact about the piece of silicon it is meant to become. That gap, between correct behaviour simulated and a manufacturable object verified, is the subject of this course.

Front-end ends at a netlist, back-end ends at a fab

Digital design splits into two halves, and the boundary is worth naming precisely because everything downstream assumes you know where it is.

Front-end design is everything you already know: write RTL, verify it against a specification, simulate it, catch bugs with testbenches and assertions. Its job ends when you have a verified gate-level netlist, the design expressed purely as standard logic gates (AND, OR, DFF, MUX and so on) wired together, with no notion yet of where any gate sits.

Back-end design, physical design, the subject of this course, takes that netlist and turns it into a manufacturable layout: real cells at real coordinates, connected by real wires on real metal layers, checked against a real fab’s rules, and streamed out as a GDSII file the fab uses to build masks.

A netlist answers “what does this circuit do?” A GDSII file answers “exactly where is every polygon on every layer?” Physical design is the process of answering the second question without breaking the answer to the first.

Note where synthesis sits in Figure 1: on the back-end side. That surprises people the first time. Writing RTL is front-end work, but turning it into gates, deciding which standard cells implement the logic and how big and fast each is, is where physical concerns first enter. From here on, every stage answers questions a testbench was never equipped to ask.

The eight-stage sequence, synthesis, floorplan, placement, CTS, routing, timing signoff, physical verification, GDSII, is the map for the whole course. Right now it is a list of names. By Module 9 you will have walked every stage with real commands and real output. This article’s only job is that you can recite the list and know roughly what follows what.

Two files, two different universes

A small exercise that makes the split concrete. Take the two artefacts that bookend this course.

A gate-level netlist, the .v file synthesis emits, is plain text. Open it in an editor and you see something like:

module counter (clk, rst, count);
  input clk, rst;
  output [3:0] count;
  wire n1, n2, n3;
  DFF_X1 _r0_ ( .CLK(clk), .D(n1), .Q(count[0]) );
  INV_X1 _g0_ ( .A(count[0]), .Z(n1) );
  // ... more gate instances and wires
endmodule

You can read it, grep it, diff two versions in a terminal and see what changed. It is a description: a list of gate instances and the wires between them, with no geometry anywhere.

A GDSII file is binary, hierarchical geometry: polygons on named layers, cell references nested inside cell references, in database units of length. There is no useful way to cat a GDSII file. You need a layout viewer (KLayout, in Section 1.2) to render it, and what you see zoomed into one standard cell is not gates and wires but coloured rectangles: polysilicon, diffusion, contacts, metal1 traces.

If you have any gate-level netlist on your machine, from the earlier course or a synthesis output you generate later, open it in a text editor and look at it: ports, gate instances, wire names. Once Module 9 gives you a real .gds, open that in KLayout and compare. Same design, two representations, two different questions.

One mistake I want to head off early: assuming that because a design works, simulates correctly and synthesizes without errors, it is close to manufacturable. Synthesis errors and functional bugs are front-end problems. Timing closure at real wire delay, congestion, IR drop and DRC violations do not exist yet at the netlist stage, and a clean synthesis run says nothing about whether any of them will be a problem later.

Practice Exercise

You are handed a gate-level netlist that simulates correctly and a GDSII file for what is claimed to be the same design. Name three questions you could answer from the netlist but not the GDSII, and three the other way round.

In the next article we zoom out one level, to the full abstraction stack from RTL down to transistors on silicon, and what a single 2-input AND gate looks like at every layer on the way.