UVM-SystemC API, Phase, Register, and Source Field Guide

How to Read This Lesson

UVM-SystemC layers a verification methodology on top of SystemC. Read names by role: object, component, phase, report, sequence, resource/configuration, TLM connection, or register model.

Standard and source context

Use Docs/LRMs/uvm-systemc-language-reference-manual.pdf. Use .codex-src/uvm-systemc/src/uvmsc and .codex-src/uvm-systemc/src/uvm.h for implementation reading.

Object and Component Families

uvm_object, uvm_component, uvm_component_registry, uvm_object_registry, uvm_test, uvm_env, uvm_agent, uvm_monitor, uvm_driver, and uvm_sequencer define the verification hierarchy.

uvm_objects, uvm_object_globals, uvm_object_string_pool, uvm_typeid_base, uvm_queue, and uvm_scope_stack are source-side helpers around object identity, storage, type lookup, and hierarchical printing.

Use uvm_object for data-like things that need factory, print, copy, compare, pack, or record behavior. Use uvm_component for hierarchical verification structure with phases and parent/child ownership.

Factory and Core Services

uvm_factory, uvm_coreservices_t, uvm_default_coreservice_t, uvm_default_coreservices_t, and factory registration macros are the override machinery. The factory is what lets a test replace a component or sequence type without rewriting the environment.

That flexibility is useful only when type names, instance paths, and override policy are documented. Otherwise factory use becomes a late-bound mystery.

Phases, Domains, and Objections

uvm_phase, uvm_process_phase, uvm_domain, build_phase, connect_phase, run_phase, phase callbacks, uvm_objection, and drain time control test execution.

uvm_phase_state, uvm_phase_states, uvm_phase_type, uvm_phase_get_run_count, uvm_run_phase, uvm_pre_reset_phase, uvm_reset_phase, uvm_post_reset_phase, uvm_pre_configure_phase, uvm_configure_phase, uvm_main_phase, and uvm_post_shutdown_phase give names to the phase graph and lifecycle states. uvm_objection_event is part of the objection notification story.

The remaining runtime phase names include uvm_post_configure_phase, uvm_pre_main_phase, uvm_post_main_phase, uvm_pre_shutdown_phase, uvm_shutdown_phase, uvm_end_of_elaboration_phase, uvm_start_of_simulation_phase, uvm_extract_phase, uvm_check_phase, uvm_report_phase, and uvm_final_phase. They make the UVM lifecycle explicit instead of hiding it inside one monolithic run function.

Build and connect phases prepare the structure. Run-time phases execute behavior. Objections tell the scheduler that useful work is still active. If a simulation never ends, inspect objections first. If it ends too early, inspect who failed to raise one.

Reporting and Message APIs

uvm_report, uvm_report_warning, uvm_report_error, uvm_report_fatal, uvm_severity, uvm_action, uvm_default_report_server, uvm_report_catcher_data, and report catchers define how verification code communicates failures.

uvm_report_message_element_base, uvm_report_message_element_container, uvm_message_defines, and uvm_globals are implementation and macro-support names that show how messages are assembled and shared across the library.

uvm_report_message_int_element, uvm_report_message_string_element, uvm_severity_name, uvm_severity_type, uvm_verbosity, uvm_tr_database, and uvm_status_container are reporting, transaction recording, and status-support names. They matter when a verification environment needs machine-readable debug output.

Prefer structured reports over raw output. A good report carries severity, component path, message ID, and enough context to reproduce the failure.

Sequence and TLM APIs

uvm_sequence, uvm_sequence_base, uvm_sequence_item, uvm_sequence_item macros, uvm_sequencer_base, uvm_driver, uvm_blocking_get_port, uvm_blocking_get_peek_port, uvm_blocking_peek_port, uvm_export_base, and UVM TLM ports/exports move stimulus and observations through the environment.

uvm_nonblocking_get_port, uvm_nonblocking_put_port, uvm_nonblocking_peek_port, uvm_nonblocking_get_peek_port, and uvm_sequencer_param_base are the non-blocking and parameterized sides of the same communication family.

uvm_seq_item_pull_imp, uvm_sequence_request, uvm_sequence_state_enum, uvm_sqr_if_base, uvm_tlm_gp, uvm_wait_op, and uvm_sc_if are sequence/TLM adapter names. If a driver and sequencer disagree, these are the kinds of interfaces you eventually trace.

The sequence/sequencer/driver split exists to separate intent from pin-level or transaction-level driving. Review that boundary carefully. A sequence should describe what to try; a driver should know how to drive it.

Configuration, Resources, and Callbacks

uvm_config_db, uvm_config_int, uvm_config_string, uvm_config_object, uvm_config_wrapper, uvm_resource_types, uvm_callback, uvm_callback_iter, uvm_callbacks, and uvm_callbacks_base provide late-bound configuration and extension points.

uvm_resource_db, uvm_typed_callbacks, uvm_event, uvm_event_callback, uvm_get_to_lock_dap, uvm_simple_lock_dap, and uvm_factory_override are source-level names around resources, callbacks, synchronization events, data-access policy, and factory override records.

uvm_resource_db_options, uvm_resource_options, uvm_set_before_get_dap, uvm_set_get_dap_base, uvm_set_config_int, and uvm_set_config_string are the option and legacy configuration names you should recognize when maintaining older UVM-style environments.

Configuration database use should be visible in the environment contract. Callback use should be treated like plugin architecture: powerful, but easy to make invisible.

Register Layer Names

uvm_reg, uvm_reg_data_t, uvm_reg_addr_t, uvm_status_e, uvm_reg_map_info, uvm_reg_file, uvm_reg_backdoor, uvm_reg_cbs, uvm_reg_cvr_t, uvm_hdl_path_concat, uvm_mem, uvm_mem_region, uvm_mem_mam, uvm_vreg, uvm_vreg_field, and uvm_path_e belong to register and memory modeling.

uvm_access_e, uvm_predict_e, uvm_reg_access_seq, uvm_reg_bit_bash_seq, uvm_reg_sequence, uvm_reg_frontdoor, uvm_reg_indirect_data, uvm_reg_read_only_cbs, uvm_reg_write_only_cbs, uvm_reg_addr_logic_t, uvm_reg_data_logic_t, uvm_reg_byte_en_t, uvm_mem_access_seq, uvm_mem_walk_seq, uvm_mem_mam_cfg, uvm_mem_mam_policy, uvm_vreg_field_cbs, uvm_hdl_path_slice, and uvm_mask_size are the deeper register/memory test and access-policy vocabulary.

uvm_reg_model, uvm_reg_fields, uvm_reg_fifo, uvm_reg_hw_reset_seq, uvm_reg_mem_shared_access_seq, uvm_reg_mem_tests_e, uvm_reg_predictor, uvm_reg_sequence_inst, uvm_reg_tlm_adapter, uvm_reg_field_cb_iter, uvm_vreg_cbs, and uvm_reg_frontdoor are register-layer source and sequence names. They are how the library connects register abstractions to bus operations, prediction, reset tests, memories, and callbacks.

The register layer exists to keep tests from hardcoding every bus detail. The model should know address maps, access policy, reset values, mirroring, frontdoor paths, and backdoor paths.

Printer, Packer, Recorder, and Compare Policy

uvm_default_printer, uvm_default_table_printer, uvm_default_tree_printer, uvm_default_line_printer, uvm_default_packer, uvm_default_recorder, uvm_default_comparer, uvm_bitstream_t, uvm_check_e, uvm_coverage_model_e, uvm_endianness_e, and uvm_elem_kind_e support generic object operations.

Also recognize uvm_recorder, uvm_line_printer, uvm_printer_knobs, uvm_printer_row_info, uvm_field_enum, uvm_radix_enum, uvm_integral_t, uvm_recursion_policy_enum, uvm_active_passive_enum, uvm_hier_e, uvm_apprepend, and the misspelled uvm_componet_name token that can appear in older/generated material.

uvm_table_printer, uvm_tree_printer, uvm_tre_printer, uvm_void, uvm_object_defines, uvm_derived_callbacks, uvm_phase_queue, and uvm_factory_queue_class are printer, macro, callback, phase-queue, and factory-support names. Treat them as implementation and utility vocabulary unless your verification environment customizes those services directly.

These names matter when a test fails and you need readable data. If sequence items do not print, compare, pack, or record clearly, debug time grows quickly.

Senior Review Checklist

• Can you identify every component's parent and phase responsibilities?
• Are objections balanced?
• Is factory override policy intentional?
• Is config-db use documented by path and type?
• Does the register model reflect firmware-visible truth?