Design
Verification

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

What every bus shares, taught on a generic link: why a bus needs rules, clocks and sampling, the valid/ready handshake, beats and transactions, pipelining and throughput, flow control, ordering and tags, byte lanes, arbitration, turning a spec sentence into a check, and a capstone bug hunt.

1. P1.1Why a bus needs rules
2. P1.2Clocks, edges and sampling
3. P1.3Handshakes: request and acknowledge, valid and ready
4. P1.4Transactions: beats, bursts, split and posted
5. P1.5Pipelining, outstanding transactions, latency and throughput
6. P1.6Flow control: backpressure, FIFO depth and credits
7. P1.7Ordering, tags and out-of-order completion
8. P1.8Addresses, widths, byte lanes and alignment
9. P1.9Arbitration, fairness and atomic access
10. P1.10From the spec to a check
11. P1.11Capstone: the generic link bug hunt

AXI as a reference: the five channels, the handshake and reset, the write and the read, outstanding transactions, bursts and the address of every beat, narrow and unaligned transfers onto memory, strobes, IDs and same-ID order, out-of-order and interleaving, the ordering model, responses and exclusive access, the request attributes, AXI4-Lite and the family, the protocol checker, a UVM agent, and a capstone bug hunt.

1. P2.1AXI in one picture
2. P2.2The handshake, the clock and reset, AXI style
3. P2.3The write transaction: AW, W and B
4. P2.4The read transaction: AR and R
5. P2.5Outstanding transactions and throughput
6. P2.6Bursts and the address of every beat
7. P2.7Narrow transfers, byte lanes and width conversion
8. P2.8Unaligned transfers: mapping any transfer onto memory
9. P2.9Write strobes, byte invariance and read-modify-write
10. P2.10IDs and same-ID order: why responses come back in order
11. P2.11Different IDs: out of order and interleaving
12. P2.12The ordering model: reads versus writes
13. P2.13Responses and exclusive access
14. P2.14Memory attributes, protection and QoS: the signals you get asked about
15. P2.15AXI4-Lite, AXI3 and AXI5: the family
16. P2.16The AXI protocol checker
17. P2.17An AXI agent, monitor and scoreboard
18. P2.18Capstone: AXI bug hunts

APB as a reference: where it sits and why every transfer takes two cycles, setup, access and the state machine, wait states, errors, strobes and protection with APB5, decoders and the read multiplexor, the AXI-to-APB bridge, the protocol checker, a UVM agent with the register adapter, and a capstone bug hunt.

1. P3.1APB in one picture
2. P3.2The transfer: setup, access and the state machine
3. P3.3Wait states and PREADY
4. P3.4Errors: PSLVERR
5. P3.5Strobes, protection and APB5
6. P3.6Many completers: decoder and read mux
7. P3.7The AXI-to-APB bridge
8. P3.8The APB checker
9. P3.9An APB agent and the register adapter
10. P3.10Capstone: APB bug hunts

AHB as a reference: the pipelined bus in one picture, address and data phases, HTRANS, wait states and what may change, the two-cycle ERROR, bursts and the address of every beat, sizes, lanes and strobes, the decoder, multiplexor and default subordinate with an APB bridge, locked and exclusive access, the protocol checker, a pipelined UVM agent, and a capstone bug hunt.

1. P4.1AHB in one picture
2. P4.2Address phase, data phase
3. P4.3HTRANS: IDLE, BUSY, NONSEQ, SEQ
4. P4.4Wait states and what may change
5. P4.5The two-cycle ERROR
6. P4.6Bursts: the address of every beat
7. P4.7Transfer size, byte lanes, strobes and width
8. P4.8Decoder, multiplexor and the default subordinate
9. P4.9Locked transfers, protection and exclusive access
10. P4.10The AHB checker
11. P4.11An AHB agent: the pipelined driver and monitor
12. P4.12Capstone: AHB bug hunts

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

Call C from SystemVerilog: the generated header and C linkage, status codes and output arguments, packed vectors and four-state bits, whole packets through open arrays, borrowed strings, models with state behind a handle, and a call back into the testbench.

1. D1.1Your first DPI-C call
2. D1.2Types, outputs and a status code
3. D1.3Packed vectors and four-state bits
4. D1.4Whole packets through open arrays
5. D1.5Strings cross as borrowed pointers
6. D1.6A model with state behind a handle
7. D1.7Calling back into the testbench

Embed Python behind the C bridge: one interpreter on the simulator thread, owned and borrowed references, packets copied into Python objects, exceptions turned into status codes, and a clocked checker that compares the design with the Python prediction before the UVM hand-off.

1. D2.1Python behind a C bridge
2. D2.2Exceptions, batches and recovery
3. D2.3A clocked checker and the UVM hand-off