Chapter 12: Virtual Platform Construction

VP Common Practices: Path Trace and Reporting Field Guide

Virtual-platform source practices for path tracing, report helpers, transaction strings, originators, and maintainable TLM utilities.

Listen to this lessonAudiobook mode

How to Read This Lesson

Virtual platforms fail slowly when observability is weak. Path tracing, initiator IDs, report helpers, and transaction-to-string utilities are not decoration. They are the tooling that tells you which model did what, when, and why.

Standard and source context

Use .codex-src/systemc-common-practices for the source examples. This is not an LRM, but it is valuable implementation guidance around reusable VP utilities.

Path Trace

Path trace is the practice of carrying or reconstructing the route a transaction took through a platform: initiator, router, bridge, target, and any adapters in between.

In a small example, a transaction print may be enough. In a real SoC VP, path trace becomes how you answer, "did this access go through the expected interconnect path, or did a decoder route it somewhere surprising?"

The common-practices repository uses names around tlm_extensions, initiator_id, and path_trace to make that route explicit without changing the base tlm_generic_payload.

Reporting Helpers

scp_report, scp_logger_cache, scp_reporting_global, scp_global_originator, scp_smoke_report_test, and report helper code sit beside the standard SystemC report mechanism.

The goal is consistency. If each block invents its own print format, platform debug becomes a text archaeology exercise. If reporting uses a common helper, severity, origin, and transaction context stay readable.

Transaction String Utilities

scp_txn_tostring and similar helpers turn a payload into something a person can read: command, address, length, byte enables, streaming width, response status, extension summary, and initiator information.

This is not just for logs. A good transaction string is also useful in assertions, scoreboard errors, and trace snapshots.

Runtime State Helpers

Names such as sc_is_running, sc_stop_called, sc_get_current_object, and sc_verbosity appear around runtime introspection and reporting behavior. They help utilities behave differently during elaboration, simulation, shutdown, or verbose debug.

Use these carefully. They are helpful for tools, but core model behavior should not become hard to reason about because it changes based on hidden global state.

VP Review Checklist

  • Can every transaction be tied back to an initiator?
  • Can a route through the interconnect be reconstructed?
  • Do report messages include hierarchy and enough transaction context?
  • Are TLM extensions cloned and cleared correctly?
  • Are utility helpers shared instead of duplicated in each peripheral?

Source-reading checkpoint

For platform-wide tracing, inspect the common-practices register path, transport_dbg, and CCI broker touchpoints together. That gives reviewers one route through traffic, state, and diagnostics. Keep tlm_target_socket, .codex-src/cci, and .codex-src/systemc-common-practices in the review trail.

Lesson self-check

Can you answer these clearly?

Keep moving when you can answer each question without looking back at the lesson.

Comments and Corrections