Python tutorials, labs & MCQs.
Python for VLSI engineers — learn to build practical automation scripts for simulation, regression, log parsing, EDA tools, coverage and reporting. Every concept is taught through real RTL and verification workflows, with code explained step by step.
Tutorials
Learn Python from beginner to advanced through structured tutorials.
Labs
Practice Python using progressively challenging hands-on labs.
MCQs
No MCQ papers for Python yet.
What Python is
Python is a general-purpose language that has become the usual place to put engineering logic living outside an EDA tool. In a chip project it is rarely the thing that runs the design — a simulator, synthesis or timing tool does that — and it is rarely the language inside the tool, which is normally Tcl. Python sits around them. It decides which runs to launch, assembles the commands, reads back the logs and reports those tools produce, turns that text into data, and returns a verdict the rest of the flow can act on. That position explains both its usefulness and its limits. Its standard library already covers files, paths, processes, text and structured data, which is most of what flow automation needs, and it stays readable enough that a script survives being handed to the next engineer. It is not a hardware description language, not a replacement for a tool's own scripting interface, and not a substitute for understanding what the tool is doing.
Why it exists
A chip project produces far more text than anyone reads: a simulation log per seed, a result per block per regression, timing and synthesis reports per corner, coverage databases per run, filelists and configuration per flow stage. Reading them is mechanical, repetitive work, and it is exactly the work people do badly under deadline — a missed UVM_ERROR in run 340 of 400 costs more than the hour it took to check the first ten by hand. Automation becomes worthwhile at the point where an operation has to give the same answer every time, state plainly when it could not, and still be correct after the engineer who wrote it has moved teams. That is a narrower claim than 'Python is faster'. Tcl, Bash and a tool's native interface each remain the better answer inside their own boundary; Python earns its place where the work is interpreting output, coordinating several runs, and producing a result somebody will make a sign-off decision from.
The part engineers get wrong
Automation fails differently from design code. A broken RTL change usually produces a visible symptom; a broken script usually produces a plausible answer. A pattern that matches nothing reports zero errors. A classifier with no verdict for a log it could not read reports PASS. A wrapper that forgets to propagate the tool's exit status lets a failed run exit 0, and the dashboard stays green. All three are silent, and from the outside all three are indistinguishable from a correct run — which is why 'it ran and produced a report' is not evidence that it worked. What prevents the whole class is not more code but a contract decided before the code: what the inputs are, what the outputs are, which conditions count as failure, and what status the tool returns. The useful question about any piece of automation is never 'did it run?' but 'what would this have done if the input had been wrong?' — and the only honest way to answer it is to break the parser on purpose and check that something fails.
Before you start
- Comfort running a command in a terminal and editing a text file
- No programming experience is assumed — Part I starts at what a value is, and needs no VLSI knowledge either
- For Part II, enough flow vocabulary to know what a simulation, a regression and a timing report are; the Python is taught, the tools and the logs are yours
What you will be able to do
- Predict what a line does from how Python binds names, rather than inferring it from syntax
- Choose a list, tuple, set or dictionary from the question being asked of the data
- Write functions with honest signatures, and know which arguments a callee can mutate underneath you
- Read a traceback back to the line that caused it, and catch only the errors you actually expected
- Read and write files with an encoding you chose instead of one the machine chose for you
- Turn a simulation log into a verdict that separates pass, fail, timeout and never-started
- Write a regular expression that fails loudly on unexpected input — and recognise the text where a regex is the wrong instrument
- Give a command-line tool an exit status the shell, CI and a job scheduler can route on
- Run an EDA tool from Python and record the exact command a human can paste to reproduce the run
- Automate a regression that isolates every job, resumes only what failed, and accounts for every result
- Extract WNS, TNS and violation counts from timing and synthesis reports without inventing a number when parsing fails
- Review someone else's automation against a written contract, and say which of its tests could never fail
The learning path
- Part I — The language, from zeroRunning your first file and reading the error it prints; values, variables and types; operators and expressions; strings
- Part I — Collections and controlLists, tuples, sets and dictionaries, and choosing between them; conditionals; loops and iteration
- Part I — Structure and robustnessFunctions and arguments; comprehensions; modules, packages and imports; errors and exception handling; file handling; object-oriented programming
- Part II — Reading what the flow producesThinking like an automation engineer; VLSI files, paths and project structures; regular expressions; simulation and UVM log parsing; structured engineering data and configuration
- Part II — Driving and coordinating toolsCommand-line VLSI tools; running EDA tools from Python; EDA environment engineering; simulation automation; regression automation; parallel regression
- Part II — Reporting, generation and trustSTA, synthesis and implementation report parsing; coverage automation; engineering report generation; generating repetitive RTL and verification artifacts; Python with Tcl and Bash; testing and debugging automation; maintainable tools; industry projects; design review
Core concepts
New to Python? Work through the curriculum in order — each lesson assumes the one before it, and the sequence is what turns the roadmap above into working knowledge.
Already working with it? Use the core-concept links above to jump straight to the topic you need; each one opens the lesson that covers it in most depth.
Where this leads
Standards: The Python Language Reference and the PEP index (Python Software Foundation) — Python has no ISO or IEEE standard: the language reference, the PEP process and the CPython implementation together define it. That is why this track states behaviour it has verified against a CPython 3 interpreter rather than citing a specification clause, and why a claim that depends on a version says so