Running a First Design End to End

Everything so far in this module has been preparation. This article is the payoff: one command, a complete flow, and a real GDSII on your disk at the end, before you have been taught how any individual stage works.

That is deliberate. Watching the whole thing run once, unexplained, gives every later module a concrete reference: “remember that stage that scrolled by on your first run? Here is what it was doing.”

The design: a small counter

Put a small RTL design in the src/ folder from the previous article. An 8-bit counter is a good choice: small enough to synthesize and route in minutes, sequential enough (a real clock, real flip-flops) to exercise every stage meaningfully, including CTS.

module my_first_design (
    input  wire clk,
    input  wire rst_n,
    output reg [7:0] count
);
    always @(posedge clk or negedge rst_n) begin
        if (!rst_n)
            count <= 8'd0;
        else
            count <= count + 8'd1;
    end
endmodule

Nothing about this design is special. It is the kind of block you wrote and verified in the earlier course. What is new is everything that happens to it next.

Running the complete flow

With config.json filled in enough to name the RTL, the clock port and a reasonable clock period (the next article covers every field; for now treat it as done), OpenLane’s autonomous mode runs the whole flow with one command:

./flow.tcl -design my_first_design

Watch the output scroll and narrate it against the stage sequence from Section 1.1. You will see these names appear roughly in this order: synthesis, floorplanning, placement, clock tree synthesis, global and detailed routing, and finally the signoff checks (timing, DRC, LVS) that close the run.

You do not need to understand any stage’s log output yet; that is Modules 2 to 9. What matters now is recognising the names. Every stage name appearing unexplained in your terminal is a module title elsewhere in this course. The course is structured to walk back through this exact run, one stage at a time, until every line you watched go by makes sense.

Finding what you built

When the run completes, its output is at designs/my_first_design/runs/<run-tag>/, following the structure from the previous article. The final GDSII is at a path like:

runs/<run-tag>/results/final/gds/my_first_design.gds

Look at that file, even only its existence and size if KLayout is not set up yet, and consider what just happened: from eight lines of sequential RTL, one command produced ready-to-fabricate mask geometry. Every polygon in that file exists because of a decision by an algorithm at some stage of the run you watched. You now have both artefacts from the first article’s comparison on your disk, the .v you wrote and the .gds the flow produced. Open both side by side if you have not.

A first successful run is not proof the design is done or good. A default flow completing without a crash tells you the flow ran. It says nothing yet about whether the resulting timing, area or power are acceptable for the design’s real requirements. Module 7 (timing signoff) and Module 8 (physical verification) are where you learn to judge a run’s results rather than confirm it finished.

Practice Exercise

Your run completes without errors and produces a GDSII. A teammate asks, “Great, is it ready to tape out?” Using only what this article covered, what is the honest answer?

In the next article, Section 1.5 goes back to the start of the run you just watched and opens the file that controlled it, config.json, field by field.