xiaoweish/uvm-source

1. This repository is the Accellera UVM reference kit for IEEE 1800.2-2020. It is not an application; it is a SystemVerilog verification framework plus examples, documentation, and a small amount of DPI/C/C++ support code.

2. The canonical implementation lives under src/. That tree is the library source that users compile into their simulator flow. The docs/html/src/ tree is a generated mirror of the same library sources, and docs/html/files/ is the generated reference manual.

3. The library is organized into major subsystems by responsibility:

• src/base: core object model, components, phases, factory, config/resource DB, reporting, objections, transactions, recording, and root services

• src/seq: sequence, sequencer, and sequence-item infrastructure

• src/comps: reusable verification components such as agent, driver, monitor, env, test, scoreboard, subscriber

• src/tlm1 and src/tlm2: transaction-level modeling interfaces, ports, exports, sockets, FIFOs, and request/response plumbing

• src/reg: register and memory abstraction, adapters, predictors, maps, fields, and built-in register sequences

• src/dap: data access policy helpers used by config-style state transfer

• src/macros: compile-time helper macros that generate common UVM boilerplate

4. The central runtime boundary is the UVM object/component hierarchy. uvm_object is the non-hierarchical base for data and transactions; uvm_component is the hierarchical base for testbench structure and participates in phasing, configuration, reporting, and factory-based construction. Everything higher-level is built on this split.

5. The execution model is phase-driven. uvm_root anchors the hierarchy and starts phase execution. Phase classes in base separate build/connect/elaboration from runtime behavior, and objections control when run-time phases drain. This is the main control-flow backbone of any UVM environment built on this repo.

6. The configuration and discovery path is split across factory, config DB, and resource DB:

• the factory handles type/name-based object and component creation and overrides

• uvm_config_db is the primary hierarchical configuration channel used by environments and tests

• the resource pool/database layer underpins broader keyed lookup and sharing

This is the main “setup-time” data flow from test top into components.

7. The stimulus path is sequencer/driver-based. Sequences generate sequence items, sequencers arbitrate and hand items to drivers, and drivers convert those items into pin-level or bus-level activity. Monitors observe DUT behavior and publish analysis traffic. This is the primary dataflow used in the examples and in user testbenches built with the library.

8. TLM is the decoupling boundary between producers and consumers. TLM1 provides analysis ports, blocking/nonblocking FIFOs, and req/rsp-style connectivity. TLM2 adds generic payloads, sockets, time annotations, and initiator/target abstractions. These subsystems are what let agents, scoreboards, predictors, and transactors communicate without tight coupling.

9. The register layer is a major subsystem on its own. src/reg models registers, fields, memories, files, blocks, maps, adapters, and predictors, and includes built-in sequences for access, reset, bit-bashing, and memory walking. It forms a bridge between abstract register models and bus-level protocols via adapters and predictors.

10. Reporting, tracing, and recording are first-class infrastructure, not add-ons. The base layer includes report objects, handlers, catchers, servers, printers, recorders, and transaction databases/streams. These are used throughout the library to control diagnostics and capture simulation activity.

11. The src/dpi directory contains the non-SV boundary into external code. It includes C/C++ and simulator-specific implementations for HDL access, regex support, and service commands. This is the main portability boundary because behavior can vary by simulator vendor and compiled DPI support.

12. compat/ and src/deprecated/ capture backward-compatibility and legacy behavior. They exist to ease migration from older UVM versions and to support older macros/APIs, but they are intentionally separate from the main clean implementation. This boundary is important when diagramming “supported core” versus “compatibility surface.”

13. examples/ is the usage/validation side of the repo. The simple examples isolate individual features like callbacks, phases, factory, TLM1/TLM2, sequences, objections, and registers. The integrated examples show complete environments with DUTs, agents, scoreboards, register models, and tests, which is the clearest illustration of the expected dataflow through the library.

14. Tooling and packaging are lightweight but important: bin/ contains helper scripts for migration and platform naming; the Makefile.* files in examples show vendor-specific build entry points; README plus DEVIATIONS.md define standard coverage and known deviations. The repo is therefore best understood as a standards-based verification library with vendor-tool integration points, not as a standalone executable system.