All programsAdvanced program
UVM Fundamentals
Architecture, base classes, phasing, factory, and config_db.
The conceptual and structural foundation of the Universal Verification Methodology: why it exists, its testbench architecture, the uvm_object / uvm_component base classes, the phasing schedule, the factory, and top-down configuration with the config_db. It sequences existing UVM tutorials into one path that prepares you to read and build real UVM environments.
6 modules33 lessons~6h 36m of reading
Prerequisites
What you'll be able to do
- Explain why UVM exists and how a UVM testbench is structured.
- Use uvm_object, uvm_component, and transaction base classes correctly.
- Sequence a testbench across the UVM phases.
- Create and override components through the factory and configure them with the config_db.
Competencies you'll develop
Verification foundations & methodology
Reason about why constrained-random, coverage-driven verification exists and how UVM evolved to standardize it.
UVM testbench architecture
Explain the UVM component hierarchy, transaction-based stimulus, and layered, reusable testbench structure.
UVM base classes
Distinguish and use uvm_object, uvm_component, and the transaction/sequence-item base classes correctly.
UVM phasing
Sequence testbench construction, connection, run-time, and reporting across the UVM phases in the correct order.
The UVM factory
Register, create, and override components and objects through the UVM factory for reusable, configurable environments.
UVM configuration (config_db)
Configure a testbench top-down with the config_db, understanding scope, hierarchy, and set/get patterns.
Curriculum
01
Verification & the road to UVM
6 lessons- 01Why Verification ExistsVerification is an engineering discipline, not a tool and not UVM — why simulation exists, why directed testing stops scaling, and how coverage-driven verification was born.
- 02Design vs VerificationThe two engineering mindsets a chip needs — the builder who makes behaviour happen and the breaker who proves it cannot go wrong — and why a strong team needs both.
- 03Verification MethodologiesDirected, constrained-random, coverage-driven, and assertion-based verification — what each is for, their blind spots, and how the modern flow combines them.
- 04Coverage-Driven VerificationFunctional vs code coverage, covergroups, bins and crosses, the closure loop, and the cardinal rule that coverage measures reach — never correctness.
- 05Evolution Toward UVMHow reuse, interoperability, standardization, and transaction-level abstraction drove the industry from ad-hoc testbenches through VMM and OVM to UVM.
- 06UVM Standardization (IEEE 1800.2)How Accellera converged OVM and VMM into UVM, what IEEE 1800.2 guarantees, the versions that matter, and coding to the standard for portability.
02
UVM Architecture
6 lessons- 07UVM ArchitectureThe fixed UVM testbench hierarchy — test, env, agent, sequencer, driver, monitor, scoreboard, coverage — and how stimulus and observation flow through it.
- 08The UVM Mental ModelThe recurring ideas for reasoning about any UVM environment — components vs objects, build-then-run, transactions over signals, configure from the top, observe and broadcast.
- 09Verification Environment OverviewThe two worlds of a UVM testbench — the static HDL harness and the dynamic class-based environment — bridged by the virtual interface, and what makes the env reusable.
- 10Transaction-Based VerificationModelling transactions with fields, constraints, and field automation, passing them via TLM, and why the transaction abstraction is the foundation of reuse.
- 11UVM Component HierarchyBuilding the named component tree with name and parent, hierarchical paths, navigating with get_parent/get_children/lookup, and how phasing walks every component.
- 12Layered TestbenchesThe abstraction layers of a UVM testbench — signal, command, functional, scenario, and test — how each builds on the one below, and expressing stimulus at the right altitude.
03
UVM Base Classes
5 lessons- 13uvm_objectThe base class for all UVM data — copy, compare, print, pack, and clone via field automation or do_* hooks, the template-method pattern, and the deep-vs-shallow-copy trap.
- 14uvm_componentThe base class for persistent structure — hierarchy, phasing, configuration, and reporting added over uvm_object, the (name, parent) constructor, and why structure extends it.
- 15uvm_transactionThe uvm_object subtype that adds transaction identity (transaction_id) and timing/recording (begin_tr/end_tr), correlation of out-of-order responses, and the base sequence items extend.
- 16uvm_object vs uvm_componentLifecycles, hierarchy mechanics, construction rules, factory vs new(), and what breaks when violated.
- 17UVM Class Library Hierarchyuvm_void → uvm_object → uvm_component — what each level adds and when to extend which class.
04
UVM Phasing
6 lessons- 18UVM Phasing OverviewThe complete UVM phase schedule — construction, run, and cleanup — zero-time function phases vs the time-consuming run task, and top-down vs bottom-up traversal.
- 19build_phaseThe top-down construction phase — getting configuration, creating children via the factory (type_id::create not new), setting children's config, and why overrides need the factory.
- 20connect_phaseThe bottom-up phase after build that wires the structure — TLM ports (port.connect(export)) and coordination handles, why it runs after build, and the connect direction.
- 21run_phaseThe one time-consuming phase where all behaviour happens — every component's run_phase runs concurrently in parallel (no ordering), and objections control end-of-test.
- 22report_phaseThe third cleanup phase — announcing results and the PASS/FAIL summary, the report server that holds the verdict, and why a printed verdict must derive from the error count, not invent one.
- 23Phase OrderingHow UVM sequences the whole schedule — the fixed phase order, top-down vs bottom-up traversal, the per-phase barrier across the tree, and run-time sub-phase synchronization.
05
The UVM Factory
5 lessons- 24Why the Factory ExistsThe problem the factory solves — substituting component and object types from the top without editing the environment, so one reusable env serves many specialized tests.
- 25The Factory PatternThe creational design pattern UVM applies — registration (uvm_*_utils builds the type_id proxy) and creation (type_id::create invokes it through the factory), and why that indirection enables type substitution.
- 26The UVM FactoryHow macros register classes, type_id::create() resolution, overrides, and the critical ordering rule.
- 27Type vs Instance OverrideWhen to choose type override vs instance, chain overrides, five dangerous pitfalls.
- 28Override Best PracticesThe disciplines that keep factory overrides predictable at scale — declare them in one place early, choose the narrowest scope, register by type not string, keep chains shallow, override only at intended seams, and always verify.
06
Configuration with config_db
5 lessons- 29uvm_config_db ArchitectureArchitecture, get/set protocol, scoping rules, virtual interface pattern, configuration objects.
- 30set() and get()The uvm_config_db set()/get() API — the four arguments, the scope string from cntxt plus inst_name, type parameterization, and the return-value check that decides whether a configuration is published and retrieved correctly.
- 31Scope RulesHow a config_db get resolves against multiple sets — glob scope matching, walking the hierarchy, and the precedence rule (higher-in-hierarchy setter wins, then last set) that lets a test override an env's defaults.
- 32Hierarchical ConfigurationBundling settings into configuration objects and nesting them into a config tree that mirrors the component tree — the top-down build-phase cascade where each level gets its config and relays each child's slice.
- 33Config PatternsThe reusable config DB idioms that turn one env into many scenarios — default-then-override layering, configuration knobs, randomized configuration, and combining the factory (types) with the config DB (values).
Completion: work through all 6 required modules (33 lessons) to develop the 6 competencies above. Reading is the medium — there is nothing to enrol in or unlock.
Assessment
PlannedHow understanding in this program would be checked. Assessment measures engineering reasoning against the competencies above — it is not part of the reading, and there is nothing to start or score here.
UVM Fundamentals — mastery assessment
Reasoning challengeA reasoning-first assessment across UVM testbench architecture, the base classes, phasing, the factory, and configuration with the config_db.
Per-module knowledge checks
- Verification & the road to UVM
- UVM Architecture
- UVM Base Classes
- UVM Phasing
- The UVM Factory
- Configuration with config_db