What CAD and Methodology Engineers Do

A modern chip is not built by one tool or one person. It passes through a synthesis tool, a place-and-route tool, a timing tool, an extraction tool and a physical verification tool, each run by a different engineer, often on a different day and on a different machine. Something has to hold all of this together so that the output of one step is a valid input to the next, and so that the same design gives the same result when it is run again next week. That something is the flow, and the people who own it are the CAD and methodology engineers.

This lesson describes the role: what the work is, how it differs from the design roles around it, and what the words flow and methodology mean in practice. The remaining nine lessons in this path then take each part of the job in turn, ending in lesson 10 with a small but complete flow built from open-source tools.

Reading time: about 9 minutes.

1.1 Where the role sits

Let us consider a team building a mid-sized block. RTL designers write the Verilog. A synthesis engineer turns it into a gate-level netlist. Physical design engineers floorplan, place, build the clock tree and route. A timing engineer signs off static timing, and a physical verification engineer runs DRC and LVS. Each of them is a user of tools.

Behind them sits a smaller group that does not own any particular block. This group decides which tool versions the project uses, writes and maintains the scripts that run each step, sets the checks that must pass before a block moves forward, and keeps the compute farm and licences usable. This is the CAD (computer-aided design) team, and in many companies it is also called the methodology team or the flow team. The names differ between companies – some keep "CAD" for tool installation and infrastructure and "methodology" for the flow content – but the work is closely related, and this path treats it as one role.

1.2 What a flow is

A flow is the ordered set of tool runs, scripts and data hand-offs that takes a design from one representation to another. The best-known example is the RTL-to-GDS flow, which starts from Verilog and ends with a layout file that can be sent to the foundry. Lesson 2 draws this flow stage by stage and lists the files that pass between the stages.

In practice, a flow is a set of files on disk: tool command scripts (usually Tcl), a few wrapper programs (often Python or shell), a configuration file per design, and something that orders the steps – a Makefile, a Python driver, or a vendor flow manager. The designer types one command, such as make route, and the flow decides which tools to start, with which inputs and which settings.

A good flow has three properties. It is repeatable: the same inputs give the same outputs. It is configurable: a new block can be brought in by editing a configuration file, not by copying and changing scripts. It is observable: each step leaves logs and reports from which the state of the design can be read. Lessons 3, 4 and 7 deal with these three properties in turn.

1.3 What a methodology is

A flow says how to run the tools. A methodology says what is good enough and in what order decisions are made. It is the set of rules, targets and checks that the project agrees on, of which the flow is one implementation.

Thus, the methodology changes slowly and is written down in documents and checklists, while the flow changes often as tools and designs change. Lesson 9 returns to methodology in the form of stage checks and signoff criteria.

1.4 Three hats: flow owner, tool expert, infrastructure

The work divides naturally into three kinds. A given engineer might wear one hat or all three, depending upon the size of the company.

Flow owner

The flow owner writes and maintains the scripts that run each stage, the configuration format, and the dependency logic between stages. When a designer reports that the route step fails on a new block, the flow owner decides whether the fault is in the design, the configuration or the flow itself. This is the hat lessons 2, 3, 4 and 10 are about.

Tool expert

The tool expert knows one or two tools in depth – for example the timing tool or the physical verification tool. This person evaluates new releases, reads the release notes for changed defaults, files cases with the vendor, and turns vendor recommendations into flow settings. A new tool version is never dropped into a project without a qualification run, because a changed default might silently change the results of every block.

Infrastructure

The infrastructure side keeps the environment usable: installed tool versions, the PDK and libraries (lesson 5), the job scheduler and queues (lesson 6), licence usage, disk space, and the regression and continuous integration system (lesson 8). Much of this work is invisible when it is done well and very visible when it is not.

1.5 A typical week

Let us consider an example week for a methodology engineer on a project nearing tape-out. The details are illustrative, but the mix is typical.

Notice that none of this work is on the design itself. Every item makes the design teams faster or their results more trustworthy.

1.6 How the role differs from design roles

A physical design engineer is measured on one block: did it close timing, did it pass DRC, did it tape out on time. A methodology engineer is measured on all blocks at once: does the flow work for every team, do results agree between runs, and are problems caught early. The table summarises the difference.

The two roles overlap heavily. Many methodology engineers started in physical design or synthesis, and that background matters: a flow written by someone who has never closed a block tends to report the wrong things. On the other hand, a design engineer who learns to write clean, configurable scripts becomes more effective in any role.

1.7 Skills to build

The skills follow directly from the three hats. It is better to build them in roughly this order, because each one rests on the earlier ones.

1. Understand the whole RTL-to-GDS flow and its file formats (lesson 2) and the PDK and library data it consumes (lesson 5).
2. Write tool Tcl and a small amount of Python that generates and launches it (lesson 3).
3. Express stage dependencies so that only what changed is rerun (lesson 4).
4. Run jobs on a shared farm without wasting cores, memory or licences (lesson 6).
5. Extract numbers from reports and compare runs (lesson 7), then automate that comparison (lesson 8).
6. Define the checks and criteria that decide when a block may move forward (lesson 9).

Lesson 10 puts all six together in one small flow.

1.8 Interview questions

What is the difference between a flow and a methodology? A flow is the executable sequence of tool runs, scripts and file hand-offs. A methodology is the agreed set of rules, targets and checks that the flow enforces, such as which checks must pass before placement or what counts as timing signoff. The flow implements the methodology.

Why should a new tool version not be used directly on a live project? A new version might change defaults, algorithms or report formats. Without a qualification run on reference blocks and a comparison of QoR, a change in results cannot be separated from a change in the design, and report-parsing scripts might also break.

What makes a flow "good"? It is repeatable (same inputs, same outputs), configurable (a new block needs a configuration file, not new scripts), and observable (every step leaves logs, reports and an exit status that tell its state).

Why is physical design experience useful in a CAD role? The flow exists to serve block owners. Knowing which reports a PD engineer actually reads, and which failures cost the most time late in a project, decides what the flow should check and report.