Interactive Versus Autonomous Execution
Section 1.4 ran an entire design with one command, and that was the right way to end that section: you needed to see the whole flow complete once before anything else made sense. But “one command, whole flow, trust the result” is the wrong habit to build from here, and this article exists to break it before Module 2.
Two ways to run the same flow
./flow.tcl -design my_first_design is OpenLane’s autonomous mode. Every stage runs back to back with no pause, and you see results only at the end, or wherever an error stops it. It is the right mode once you already trust a design and want a full rerun.
OpenLane also has an interactive mode: a Tcl console where you run one stage at a time, explicitly, and the flow stops after each one, leaving you free to inspect what that stage produced before continuing.
Why this course uses interactive mode from here on
This is not a stylistic preference. The point of Modules 2 to 9 is understanding what each stage’s real inputs and outputs are: what a post-synthesis netlist looks like before floorplanning touches it, what a placement density report says before CTS runs, what a routed design’s DRC report shows before signoff. None of that is visible if the flow runs start to finish and you only see the final result.
Interactive mode makes every intermediate artefact something you stop and look at before trusting the pipeline to chain them together. Autonomous mode is what you use after you have built that trust; interactive mode is how you build it. It mirrors a debugging habit from the Verilog course: running a full simulation and checking only the final result tells you whether something is wrong; stepping through a waveform tells you why. Real teams use both modes: scripted autonomous runs for regressions on designs they understand, and interactive sessions when debugging a new problem or learning a new design, which is your situation for the rest of this course.
Your first two interactive commands
From Module 2, every lab in this course runs through the interactive console rather than flow.tcl. The first two commands in every one of them:
prep -design my_first_design
run_synthesis
prep -design my_first_design starts an interactive session for a design: reads its config.json, creates a fresh run directory and loads the PDK data the session will use, without running any stage. run_synthesis runs exactly one stage, synthesis, and stops, so you can inspect the netlist and synthesis reports before anything else.
That is the pattern the course repeats, stage after stage: prep, one run_<stage>, a deliberate pause to look at what it produced, then the next run_<stage>. Running every run_<stage> back to back with no pause “to save time” turns interactive mode into autonomous mode with extra typing. The value is entirely in the pause.
Practice Exercise
You are debugging a design whose final routed result has surprisingly poor timing, and you suspect the problem was introduced before routing but do not know at which stage. Using interactive mode, describe the strategy for narrowing it down.
Solution
Run the flow interactively from the beginning, checking a relevant report after each run_<stage> rather than running through to routing. Concretely: prep, then run_synthesis and check the synthesis timing and area reports for anything already concerning; if fine, run_floorplan and check utilisation and early warnings; then run_placement and inspect density or congestion; and so on, looking for the first stage whose report shows a warning sign, rather than waiting for the final signoff report to reveal a problem whose origin could be anywhere upstream. This is the “find the first anomaly, not the most visible symptom” discipline from RTL debugging, applied to flow stages instead of simulation time, and interactive mode is what makes it possible.
That closes Module 1. In the next module we put all of this to work: opening up synthesis, running Yosys against real RTL and real SKY130 cells, and reading a first genuine synthesis report.