Tcl Across the Semiconductor Flow

Part II · Module 16 · Chapter 16.2 · Tcl Across the Semiconductor Flow

This chapter is a map. It does not teach any tool command — later modules do that. Its job is to give you somewhere to put them, so that when create_clock appears in a later module you already know which stage it belongs to and what it is for.

The short version: Tcl is the control layer for most of the flow. The same language, with a different command set at each stage.

1. The stages

Real flows are messier — stages iterate, overlap and repeat — but this ordering is enough to hang the commands on.

2. Constraints

Timing constraints say what the design must achieve: how fast each clock runs, how much of a cycle is available at the boundary, which paths do not matter.

They are written in SDC — Synopsys Design Constraints — and the single most useful fact about SDC is that it is Tcl. An .sdc file is a Tcl script whose commands happen to be constraint commands:

create_clock -name clk -period 2.0 [get_ports clk]
set_input_delay  0.4 -clock clk [get_ports data_in]
set_output_delay 0.3 -clock clk [get_ports data_out]

Because it is Tcl, everything from Part I is available inside a constraints file — a variable for a period used in three places, a foreach over a list of ports, an if on which corner is being built. That is genuinely common and it is why constraint files are maintainable at all.

3. Simulation and formal

Functional verification mostly happens in SystemVerilog, not Tcl. But the tool driving it is controlled by Tcl: compiling the sources, elaborating, running, setting breakpoints, dumping waveforms, and deciding what counts as a pass.

A simulation run script is Tcl that invokes the simulator's own commands, and a regression is a Tcl loop over tests that collects results and returns an exit status. That is Chapter 15.4 doing real work.

4. Synthesis

Synthesis turns RTL into a gate-level netlist. The script is Tcl from beginning to end, and its shape barely varies between projects:

read_verilog  {cpu_top.v alu.v fifo.v}      ;# tool commands, not Tcl
link_design   cpu_top
read_sdc      constraints.sdc
compile_ultra
write_verilog cpu_top_mapped.v
report_area
report_timing

Every word after the command name is an ordinary Tcl argument, and the whole file is an ordinary Tcl script. A real one wraps those lines in the structure from Chapter 15.9 — a block name from argv, paths built with file join, each step checked, a non-zero exit if anything failed.

5. Place and route

Physical design places the gates and wires them together. Again the flow is a Tcl script: floorplan, power grid, placement, clock tree, routing, each a tool command with options, interleaved with checks.

Two things make Tcl especially valuable here. The runs are long — hours, sometimes days — so a script that fails informatively at minute three instead of hour six is worth a great deal. And the stage is iterative: the same script runs many times with different parameters, which is exactly what command-line options are for.

6. Timing signoff and reports

Static timing analysis checks every path against the constraints, across process corners and operating conditions. This is where Tcl scripting earns its reputation, because the questions are open-ended:

• Which endpoints fail, grouped by clock domain?
• Of the failing paths, how many are fixable by resizing one cell?
• Did this run get worse than the last one, and where?

No tool can anticipate all of those, which is Chapter 16.1's argument in its most concrete form. You write them, with the tool's query commands inside ordinary Tcl loops and conditionals.

Report collection then sits at the end of everything: walk a directory of runs, pull one number out of each, build a table, decide whether the flow proceeds. That is Part I almost entirely — files and paths, regular expressions, dictionaries, and an exit status.

7. The shape that repeats

Here is what is worth noticing about the whole map. At every stage, the Tcl you write has the same shape: iterate over something, do tool work, catch failures, count them, report, return a status.

This runs in a plain tclsh — the stage work is stubbed out, because the shape is the point:

proc run_stage {name blocks body} {
    set failed {}
    foreach b $blocks {
        if {[catch {uplevel 1 [list apply [list {block} $body] $b]} err]} {
            puts stderr "  $name: $b FAILED: $err"
            lappend failed $b
        } else {
            puts "  $name: $b ok"
        }
    }
    return $failed
}

set blocks {cpu_top fifo_ctrl alu_core}

set bad [run_stage "synth" $blocks {
    if {$block eq "fifo_ctrl"} { error "unmapped cell" }
    return "gates"
}]
puts "  -> [llength $bad] block(s) failed synth: $bad"

set bad [run_stage "sta" $blocks {
    return "timing met"
}]
puts "  -> [llength $bad] block(s) failed sta: $bad"

  synth: cpu_top ok
  synth: fifo_ctrl FAILED: unmapped cell
  synth: alu_core ok
  -> 1 block(s) failed synth: fifo_ctrl
  sta: cpu_top ok
  sta: fifo_ctrl ok
  sta: alu_core ok
  -> 0 block(s) failed sta:

Replace the stubbed bodies with real tool commands and that is a flow driver. The catch, the failure list, the per-item message on stderr and the count at the end are all Module 14 and Module 15, unchanged.

That is the useful thing to take from this map: the stages differ in what they ask the tool to do, and barely at all in how the Tcl around it is written.

8. What is not Tcl

Worth stating plainly, so you do not go looking:

• RTL is Verilog, SystemVerilog or VHDL. Tcl reads it in; it is not written in Tcl.
• Testbenches are SystemVerilog, usually UVM.
• Libraries and timing models are Liberty, and layout is GDSII or OASIS. Binary or structured formats, not scripts.
• Flow orchestration above the tools — which jobs run on which machines, in what order — is usually Make, Bash, Python or a workload manager. Tcl's reach stops at the edge of the tool it lives in.

That last one is the subject of Chapter 16.3.

9. Where later modules attach

The map, with the module that teaches each part:

If you remember one thing from this chapter, make it this: when you meet an unfamiliar command, the first question is which stage does this belong to — because that tells you what state it expects to exist and what it is likely to return.

10. Exercises

Exercise 1. What language is an SDC constraints file written in?

Exercise 2. Why does that make constraint files more maintainable than a plain settings file?

Exercise 3. Are read_verilog and link_design Tcl commands?

Exercise 4. Name two reasons Tcl is particularly valuable during place and route.

Exercise 5. Why is timing signoff the stage where scripting matters most?

Exercise 6. What shape does the Tcl take at essentially every stage?

Exercise 7. Name three things in a chip flow that are not Tcl.