Choose your
next lesson.

Choose data types that keep unknown values visible, lay bits out the way the wire does, and report failures clearly.

1. 1.1Four-state vs two-state types
2. 1.2Packed vs unpacked arrays
3. 1.3Structs and unions
4. 1.4Enums, typedef and casting
5. 1.5Strings and useful diagnostics
6. 1.6Problem: decode a register address
7. 1.7Debug case: the X that became zero

Hold bursts, queues of expected responses and outstanding IDs in the collection that fits, and keep every lookup honest.

1. 2.1Fixed and dynamic arrays
2. 2.2Queues and ordering
3. 2.3Associative arrays and transaction IDs
4. 2.4Array methods and with expressions
5. 2.5Problem: missing burst beats
6. 2.6Collection copies and cost
7. 2.7Debug case: stale IDs after reset

Write tasks and functions that behave when called concurrently, start and stop processes on purpose, and pass work between them without lost wakeups or deadlocks.

1. 3.1Tasks, functions and arguments
2. 3.2Automatic and static lifetime
3. 3.3Fork, join and cancellation
4. 3.4Events and persistent state
5. 3.5Mailboxes and backpressure
6. 3.6Semaphores, ownership and deadlock
7. 3.7Problem: a bounded response wait

Model transactions as objects: create one per transaction, copy them deliberately, extend them for error injection, and let each object answer for itself.

1. 4.1Handles, objects and constructors
2. 4.2Shallow copies and deep copies
3. 4.3Inheritance and super.new
4. 4.4Virtual methods and dynamic dispatch
5. 4.5Checked casts and type safety
6. 4.6Parameterized classes and static members
7. 4.7Problem: a transaction factory

Generate legal bus bursts with constraints, control and measure how often each kind appears, and make a failing random test reproducible.

1. 5.1Rand fields and checked randomization
2. 5.2Inside, implication and distributions
3. 5.3Solve order and distribution bias
4. 5.4Soft constraints and inheritance
5. 5.5Randomization modes and frozen state
6. 5.6Random stability and callbacks
7. 5.7Problem: a legal burst generator

Bundle the pins into interfaces, drive and sample them at well-defined points in each time step, and check the handshake on every edge.

1. 6.1Interfaces and modports
2. 6.2Scheduling regions and nonblocking updates
3. 6.3Clocking blocks and sampled views
4. 6.4Virtual interfaces and driver configuration
5. 6.5Ready/valid drivers and backpressure
6. 6.6Assertions and protocol checks
7. 6.7Debug case: a racing monitor

Specify a FIFO, build it, and verify it with a complete layered testbench that reuses everything from Modules 1 to 6.

1. 7.1Start from the FIFO rules
2. 7.2Implement the FIFO and its boundaries
3. 7.3Build the generator and driver
4. 7.4Build the monitor and scoreboard
5. 7.5Coverage and tests for the checker
6. 7.6Reset, wrap and reproducible stress
7. 7.7Capstone: the complete layered testbench

Map a layered testbench onto UVM components, follow the order in which phases visit the component tree, and keep the run phase open exactly as long as work is in flight.

1. U1.1From a layered bench to UVM
2. U1.2Build, connect and observe the phase order
3. U1.3Objections and premature completion
4. U1.4One environment, a family of tests

Copy and compare transactions safely, let a test swap classes through the factory, and deliver configuration and virtual interfaces to the components that need them.

1. U2.1Copy, clone and transaction ownership
2. U2.2Factory creation and type substitution
3. U2.3Configuration paths and virtual interfaces
4. U2.4Print, pack and record a transaction

How UVM code reaches other code: virtual and pure virtual methods and interface classes, TLM-1 ports, exports and imps with the direction of every call and every data move, blocking and non-blocking calls through FIFOs and channels, analysis broadcast, and the sequencer-driver link and callbacks as the same pattern.

1. U3.1Contracts in classes
2. U3.2Ports, exports and imps: who calls whom
3. U3.3The TLM-1 family: interfaces, flavours and masks
4. U3.4Blocking, non-blocking, FIFOs and channels
5. U3.5Analysis ports: one call, many listeners
6. U3.6The connections you already use, and callbacks

Send items from a sequence through the sequencer to a driver, read the handshake in a log, route responses back to the right sequence, and drive a clocked bus that pushes back.

1. U4.1Sequences and the item handshake
2. U4.2Responses and routing
3. U4.3A driver on a clocked bus

Measure the six arbitration modes and the priority rules on one bench, give a sequence the driver with lock and grab, keep one out with is_relevant, learn the sequence lifecycle, read the macros, libraries and default sequences that start stimulus, and synchronise with events, barriers and a heartbeat.

1. U5.1Arbitration and priority
2. U5.2Lock, grab and relevance
3. U5.3The sequence lifecycle
4. U5.4Sequence libraries, macros and default sequences
5. U5.5Events, barriers and heartbeats

Fill a pipelined bus with a multi-threaded get/put driver, answer a bus master from a reactive agent whose responder sequence decides every reply, and stack a packet layer over a byte link with a translator sequence and a reconstruction monitor.

1. U6.1Pipelined drivers
2. U6.2Reactive agents
3. U6.3Layered protocols

Turn pin activity into transactions at the edge where the design takes them, decide who copies a transaction and when, and check results in order with a scoreboard that accounts for every input and ends only after a quiet window, and route the assertions of a bound interface checker into the same UVM verdict.

1. U7.1Monitor the event the DUT accepts
2. U7.2Who owns an analysis transaction
3. U7.3Scoreboard accounting and drain checks
4. U7.4Checks in interfaces: SVA inside a UVM bench

Split checking into prediction and evaluation, key predictions by tag when a design answers out of order, decide what makes a transaction correct, and measure latency and bookkeeping so that zero errors cannot hide zero checks.

1. U8.1Predictor, comparator, scoreboard
2. U8.2Out-of-order checking
3. U8.3Comparing is not equality
4. U8.4Metric analyzers and the ledger

Where the prediction comes from: choosing a checking strategy, an untimed model and its sync point, a C model behind DPI, TLM-2.0 sockets, and an instruction-set model compared at each retire as in a virtual-platform flow.

1. U9.1Choosing the checking strategy
2. U9.2An untimed model and the sync point
3. U9.3A C reference model behind DPI
4. U9.4TLM-2.0 sockets for a reference model
5. U9.5Virtual platforms and refine-and-reuse

Drive several interfaces from one virtual sequence, reset the design in the middle of traffic without leaving the sequencer, driver or scoreboard behind, and put deadlines on every wait so a stuck test fails fast with a useful message.

1. U10.1Coordinate two sequencers
2. U10.2Reset in the middle of traffic
3. U10.3Bound work and prove completion

Reuse one agent at block and chip level: make it passive where another block drives the pins, give each copy its own configuration object, and replace the driver inside one agent only.

1. U11.1Build an active or passive agent
2. U11.2Give each instance its own configuration
3. U11.3Override one instance

Extend a component without editing it, with callbacks and the choice between callback, override and knob; reuse a block environment inside a subsystem with its checks intact; and connect a bench to a legacy BFM that has no interface.

1. U12.1Callbacks: extend a driver from the test
2. U12.2Vertical reuse: a block environment inside a subsystem
3. U12.3When there is no interface

Describe the incrementer's registers in a UVM register model, tell its desired value from its mirror, drive real APB transfers through an adapter, and keep the mirror right when other code writes the bus.

1. U13.1Desired values, mirrors and reset
2. U13.2An APB adapter and frontdoor access
3. U13.3Predict from observed bus traffic

Reach the register slice through its frontdoor and a hand-written backdoor, run the built-in register tests, model quirky registers, program a configuration from the model, and assemble generated models into a chip with two ports.

1. U14.1Memories and a backdoor without VPI
2. U14.2Built-in register tests and quirky registers
3. U14.3Register-driven configuration and coverage
4. U14.4Several maps, sub-blocks and generated models

Place coverage where it proves what the design did and trace it to the plan; find a bench bug from its symptom with the library's debug tools; and measure and remove the costs that make a large bench slow or make its memory grow.

1. U15.1Coverage architecture and planning
2. U15.2Debugging by symptom
3. U15.3Performance and scale

Make reports support a verdict, record how random stimulus was seeded, close coverage holes on purpose, and assemble a complete UVM bench for a four-entry FIFO, then verify an APB peripheral with the whole track's machinery and localise a planted bug from the report.

1. U16.1Reports that support a verdict
2. U16.2Seeds, coverage and directed closure
3. U16.3The integrated UVM FIFO capstone
4. U16.4The APB peripheral capstone

What an assertion checks and when: immediate, deferred and concurrent assertions, the values a clock edge samples, and the attempt every edge starts, which can pass, fail or pass vacuously.

1. A1.1Why assertions
2. A1.2Clocks and sampling
3. A1.3Implication and vacuous success

Describe timing with fixed delays, ranges and repetition, see the threads one attempt forks, put two obligations on one trigger, and count protocol events with auxiliary code.

1. A2.1Delays and ranges: one attempt, many threads
2. A2.2Repetition and counting events

What the end of a test means for weak and strong properties, how to say that a condition holds until an event, and how reset and abort conditions end attempts.

1. A3.1Weak and strong: what the end of a test means
2. A3.2Holding until an event: until and throughout
3. A3.5Reset and abort: disable iff, accept and reject

Carry a value from a request to its response with local variables, and pair responses with the requests they answer.

1. A4.1Remembering data with local variables
2. A4.2Tags: one response must not satisfy every request

Concurrent assertions placed inside always blocks, with the clock and enable they take from the procedure, and sequences used as events that wake procedural code.

1. A5.1Assertions in procedures, sequences as events

Write rules once as named sequences and properties, keep them in a module of rules, and bind them into designs you cannot edit.

1. A7.1Packaging and binding

Plan and write complete assertion suites, for a FIFO and for a tagged request/response channel, that fire on every faulty design and stay silent on the correct one.

1. A8.1Capstone: an assertion suite
2. A8.2Capstone: a tagged request/response channel

Prove what your tests exercised: build coverage models with covergroups, find the holes, and close them with constraints.

1. C1What coverage measures
2. C2Covergroups and coverpoints
3. C3Choosing bins
4. C4Transitions
5. C5Cross coverage
6. C6Coverage in a class
7. C7Closing holes
8. C8Capstone: a coverage model that finds holes