UVM Report Server Version compatibility - new UVMLint rule

Troubleshooting UVM Report Server Fractures: When UVM 1.2+ Code Meets a UVM 1.1d Environment

When maintaining legacy testbenches or integrating modern third-party Verification IPs (VIP), engineers frequently hit a brick wall: code written using modern UVM idioms fails with catastrophic compile errors when forced into a UVM 1.1d environment.

The root cause is a silent, backward-incompatible structural redesign of the UVM reporting API that occurred between UVM 1.1d and UVM 1.2.

The Architectural Shift

If your code was written for UVM 1.2 or IEEE 1800.2, it likely utilizes uvm_default_report_server and overrides compose_report_message. When this code hits a UVM 1.1d simulator, the compilation crashes because those components literally do not exist yet.

In UVM 1.1d, uvm_report_server is a concrete base class, and formatting relies on scalar string/integer arguments. In UVM 1.2+, uvm_report_server was turned into a virtual class, its concrete implementation was moved to uvm_default_report_server, and log metadata was encapsulated into a uvm_report_message object wrapper.

Feature	Modern Code (UVM 1.2 / IEEE)	Legacy Environment (UVM 1.1d)
Base Class	uvm_default_report_server	Does not exist (Must use uvm_report_server)
Formatting API	compose_report_message(...)	Does not exist (Must use compose_message)
Arguments Type	Handle (uvm_report_message)	Scalars (severity, id, message, etc.)

The Compile-Time Breakage

Because of this shift, your UVM 1.2-compliant code will throw fatal compilation errors in a 1.1d environment:

// Triggers "Class 'uvm_default_report_server' is not defined" in UVM 1.1d
class custom_report_server extends uvm_default_report_server;
  
  // Triggers signature mismatch / unknown type 'uvm_report_message' in UVM 1.1d
  virtual function string compose_report_message(uvm_report_message report_message, ...);
    // ...
  endfunction
endclass

The Solution: Backward-Compatible Guarding

To allow your modern UVM 1.2+ code to gracefully fall back and compile under UVM 1.1d without maintaining two separate repositories, leverage UVM version preprocessor tokens to isolate class definitions:

`ifdef UVM_POST_VERSION_1_1
  // Your original modern style (UVM 1.2+)
  class custom_report_server extends uvm_default_report_server;
    virtual function string compose_report_message(uvm_report_message report_message, ...);
`else
  // The legacy fallback (UVM 1.1d)
  class custom_report_server extends uvm_report_server;
    virtual function string compose_message(uvm_severity severity, string name, ...);
`endif

Implementing a Custom Rule in AsFigo BYOL (Build Your Own Linter)

To automatically catch this environment hazard before it breaks customer regressions, we can write a custom rule inside the AsFigo BYOL infrastructure. Whether your pipeline leverages the concrete AST/CST of open-source parsers like Google Verible or Slang, or hooks into commercial platforms like Synopsys Verdi, the logic remains identical.

Rule Definition: UVM_ERR_REPSERVER_LEGACY_COMPAT

• Severity: Error
• Description: Detects modern UVM 1.2+ report server classes and types that lack preprocessor version guarding, preventing compilation failures in standard UVM 1.1d environments.

Example AsFigo Linter Output

[UVM_ERR_REPSERVER_LEGACY_COMPAT] uvm_server_test.sv:12: Reference to modern type uvm_default_report_server found outside of an explicit version preprocessor conditional block. This code will fail to compile in legacy UVM 1.1d environments. Wrap the block in `ifdef UVM_POST_VERSION_1_1.