Where Python Sits in an RTL-to-Signoff Flow

Module 1 · Chapter 1.1 · Where Python Sits in an RTL-to-Signoff Flow

1. The Engineering Problem

A nightly regression finishes at 04:10. It ran 600 simulations: 40 tests across 15 seeds each.

At 09:00 somebody has to answer four questions before the team's stand-up:

• How many of the 600 passed?
• Which failures are new since yesterday?
• Of the failures, how many are actually the same bug seen 30 times?
• Did coverage move?

The answers are all sitting in the run area already. Every simulation wrote a log. Every log contains the lines that decide whether that run passed. Nothing is missing — the information exists, in 600 files, as text.

And yet answering those four questions by hand takes an engineer most of a morning, every morning. Opening logs. Searching for UVM_ERROR. Copying test names into a spreadsheet. Noticing, on the third pass, that two failures were counted twice and one test never started at all.

This chapter is about where in your flow those gaps appear.

2. The Flow You Already Know

Before we put Python anywhere, let us agree on the flow. You know this chain — it is the spine of every block-level project:

Two properties of this chain matter more than anything else in this chapter.

First: every stage is a program you launch with a command. You do not click a compile button. Something types a command with a list of arguments, waits for the tool to finish, and then finds out whether it worked.

Second: every stage answers in text. The compiler writes a compile log. The simulator writes a simulation log. The coverage tool writes a coverage report. Timing analysis writes a timing report. These are files full of lines, and the decision "did this pass?" is made by reading them.

3. Where Python Goes

Now put Python on the same picture. Python does not go inside any stage. It goes in the gaps between and around them.

There are four jobs, and you have done all four by hand:

That is the whole shape of the Python work in a verification flow: launch, read, decide, report. Everything in the remaining 22 modules of this track is one of those four jobs, done well.

The smallest possible example of "read"

Here is the read job at its smallest. This is a preview — you are not expected to be able to write it yet, and we are not going to teach the syntax in this chapter:

for line in log:
    if "UVM_FATAL" in line:
        fatal_count += 1

Read it as English rather than as code:

• log stands for one simulation log file.
• for line in log: means go through the file one line at a time, and call the current line line.
• "UVM_FATAL" is the exact text we are looking for. The quotes mean this is literal text, not the name of something.
• in asks a question: does that text appear anywhere inside this line?
• The colon : at the end of a line means what follows, indented, belongs to this instruction. Indentation is how Python shows which lines are inside which — it is doing the job that begin/end does in SystemVerilog.
• fatal_count += 1 means take the current count, add one, and store the new value back. (Something has to set fatal_count to 0 before the loop starts — that is Module 3, and it is left out here so the three lines stay about the idea.)

So the three lines say: go through the log one line at a time; whenever a line contains UVM_FATAL, add one to the count.

That is it. Three lines, and it does the thing you do with your eyes — except it will do it identically to the 600th log.

4. The Four Jobs, Stage by Stage

Now walk the flow again and name where the four jobs land. This is the map you should carry out of this chapter:

Every row is the same four jobs. That is why one language can serve the whole flow: the flow is not five different problems, it is one problem five times.

One command line is worth showing, because it is the shape every later module builds toward:

python run_sim.py --test axi_smoke --seed 4210

axi_smoke  seed 4210   PASS   0 errors   182.4 s

You give it a test name and a seed. It compiles if needed, runs the simulator, reads the log, decides the verdict, and tells you. We build exactly this tool, step by step, in Module 14 — and the very first version of it in Module 2.

5. What Python Does Not Do

This is as important as the last section, and it is where a lot of confused advice lives.

Python does not replace any of these:

• Your RTL. The design is SystemVerilog or VHDL. Python does not describe hardware.
• Your testbench behaviour. A UVM driver, a sequence, a scoreboard — those are SystemVerilog classes running inside the simulator.
• Your assertions. SVA is checked by the simulator, cycle by cycle, with access to the design's internal state. A script reading a log afterwards cannot do that.
• The tool engines. Compilation, simulation, synthesis and timing analysis happen inside the vendor's tool.
• Tool-native scripting, where the tool owns the job. Many EDA tools have their own command interpreter — usually Tcl — with direct access to the loaded design database. Work that needs get_cells or report_timing on a live database belongs there, not in Python.

6. Why This Is Verification Work

There is a belief worth addressing directly, because it holds people back: automation is scripting, and scripting is not really verification.

Look at what the code in §3 actually decides. It decides whether a simulation passed.

If that count is wrong — if the script looks for UVM_ERROR but the environment reports failures as UVM_FATAL, or if it reads a log that was truncated when the job was killed — then a failing test is reported as passing. The regression is green. Nobody looks at the waveform. The bug ships.

That is why this curriculum takes automation seriously enough to test it (Module 17), review it (Module 23), and be careful about what it claims. The script is not support infrastructure sitting next to the verification. On a regression, the script is the thing reporting the result.

7. Common Wrong Mental Models

Three ideas people bring to this, and the correction for each:

"Python is for software engineers." The audience for this curriculum is the person who owns the regression. The value of Python here is not software craft — it is that 600 logs get read the same way every night. That is an engineering result, not a programming one.

"I'll learn Python properly first, then apply it." This fails for most engineers because generic Python material spends weeks on problems you do not have. This track inverts it: Module 2 has you writing a useful log checker before you have met a function.

"My flow is already automated — it's all in Bash and Makefiles." Quite possibly, and some of it should stay there. Chapter 1.3 is entirely about where that boundary sits, and it does not conclude "rewrite it all in Python."

8. Exercises

Reasoning only. No code — you have not been taught any yet, and these do not need it.

Exercise 1 — Find the four jobs in your own flow

Take one thing you did by hand last week: a re-run of a failing test, a coverage check, a log you searched through. Write down which of launch / read / decide / report you performed, in order. Most tasks turn out to be all four.

Exercise 2 — Name the text

For three stages of your own flow, name the file the stage produces and the single line or number inside it that decides the outcome. For a simulation, that might be sim.log and the presence of UVM_ERROR. This is the habit the whole parsing half of the track is built on: find the text that carries the decision.

Exercise 3 — Draw the boundary

For each of the following, decide whether it belongs inside the simulator or outside it, and say why in one line: (a) checking that ready rises within five cycles of valid; (b) deciding which 40 tests tonight's regression should run; (c) driving a randomized transaction onto a bus; (d) noticing that 30 of tonight's failures have the same first error message.

Exercise 4 — The silent failure

A colleague's script counts UVM_ERROR lines and reports PASS when the count is zero. Name two realistic situations in which a simulation genuinely failed and this script would still report PASS. (Hint: what does the script do if the test was killed before it finished? What if the environment reports this failure at a different severity?)

9. Related Tutorials

The flow this chapter maps Python onto:

• The Typical VLSI Design Flow — the RTL-to-signoff chain of Figure 1, taught as a design flow rather than as an automation surface.
• The UVM Report Server — where UVM_ERROR and UVM_FATAL actually come from, and why their severity is a decision a parser has to respect.
• Introduction to Functional Coverage — the coverage stage named in Figure 1, before any script goes near its report.

Automation already living in the flow:

• GLS in Regression — the same launch, read, decide, report shape applied to gate-level simulation.

10. Summary

• The flow is a chain of programs that are launched with commands and that answer in text. Compile, simulate, regress, measure coverage, report — every stage takes text in and produces text out.
• Python's work is four jobs: launch, read, decide, report. Every module in this track is one of those four, done more carefully than the last time.
• Python goes around the simulator, not inside it. Your RTL stays SystemVerilog, your testbench stays UVM, your assertions stay SVA, and work that needs the tool's live design database stays in the tool's own language.
• Whatever decides pass or fail is verification work. A script that silently calls a failing run PASS is a hole in your verification, which is why this track tests and reviews its automation rather than just writing it.
• The gap Python fills is not difficulty, it is reliable repetition. Reading one log is easy; reading 600 the same way every night is not something a person can do.

You should now be able to look at a stage of your own flow and say whether Python belongs around it, and what it would be doing there.

The next chapter asks a fair question from the other direction: your team already has scripts, many of them in older languages, and they work. Chapter 1.2 — Why Flow Scripts Moved to Python is about what actually changed to make teams reach for Python for new automation, stated without pretending the older scripts disappeared.