UVM on Verilator: Mapping the Minefield (The Technical Deep Dive)

While our previous posts focused on the strategic "Why," this post addresses the "How." Porting 50+ production-grade UVCs wasn't a matter of simple recompilation. It was an exercise in uncovering the delta between commercial simulator "permissiveness" and the strict reality of the SystemVerilog LRM and the Verilator execution model.

Here are the some of the primary technical roadblocks we mapped and cleared. 

You can learn lot more at our upcoming event on Thursday, get your tickets today: https://buytickets.at/asfigo/2091884 

1. Strict LRM & Parsing Enforcement

Commercial tools have historically been "lazy" with LRM enforcement. Verilator is not. Code that has run for years in proprietary silos often fails immediately here due to:

  • SVA: Basic temporals do work, not complex ones. We have ported AHB, APB and AXI4-Lite SVA IPs to Verilator, so though this sounds very limiting, in reality, it is not that bad!
  • Range Syntax: Not so un-common, but non-compliant packed ranges like [63_0] are flagged.
  • Parameter Strictness: Missing parameter defaults and invalid interface port declarations are no longer "guessed" by the compiler; they require explicit LRM compliance.

2. UVM Versioning & Encapsulation

Verilator is built for the modern era, supporting UVM 1.2 and IEEE 1800-2017. While the bulk of VIPs are being updated, we found that approximately 30% of the codebases we encountered still rely on legacy constructs or "loose" scoping:

  • Legacy/deprecated Constructs: Macros like the uvm_do_on family, and deprecated objects like uvm_test_done or legacy uvm_top shortcuts, do not resolve natively.
  • Access Violations: Illegal direct access to local or protected UVM members is strictly blocked.
  • Phase Management: Implicit behaviors, such as starting_phase being auto-provided (UVM 1.1d), are not supported, leading to local access violations during phase_done.
  • The Migration Path: While AsFigo has developed a temporary compatibility mode (a shim layer) to bridge these gaps, we strongly encourage users to migrate to full IEEE-compliant 1.2+ syntax for long-term stability.

3. Template & Type Resolution

The elaboration engine in Verilator demands absolute type clarity. We encountered several bottlenecks where the resolution of complex types broke down:

  • Recursive Templates: Deeply nested or recursive parameterized classes can lead to resolution failures during elaboration.
  • Typedef Requirements: Missing explicit typedefs often lead to "unknown type" errors, as Verilator requires a clear type map.
  • Virtual Enforcement: A pure virtual method in a class that isn't explicitly declared as a virtual class will trigger a failure—a common relaxed syntax in some tools.

4. The "Final Boss": Scheduling & Phasing

The most difficult issues to root cause weren't syntax-based—they were execution-based.

  • The #0 Support: Relying on #0 to resolve race conditions is a high-risk strategy in Verilator’s optimized execution model.
  • The OBJTN_CLEAR Error: This dreaded UVM phasing/objection error was the most significant hurdle. It required a massive, coordinated effort from the worldwide Verilator R&D team to fix, ensuring that UVM objection clearing and phase transitions synchronize correctly in a compiled model.

The Codified Solution

We didn't just document these errors; we embedded them into the UVMLint and SVALint engines. These tools now serve as the deterministic backbone for our agentic AI flow, ensuring that any code—whether human or AI-generated—is validated against these production-proven constraints.

Coming up next: How we scale this across AWS infrastructure without hitting the "RAM Wall."

You can learn lot more at our upcoming event on Thursday, get your tickets today: https://buytickets.at/asfigo/2091884 


Comments

Post a Comment

Popular posts from this blog

Join Us in Cambridge - Advancing Chip Verification with UVMLint & SVALint

AsFigo invites you to our next technical session, focused on enabling semiconductor design teams to adopt open-source EDA tools—especially for testbench linting workflows. Remote-dial-in link:  UVMLint meetup - Cambridge, June 27 | Meeting-Join | Microsoft Teams 📍 Event: UVMLint & SVALint – Enablers to Move Your Chip Design Ahead 📅 Date: Friday, June 27, 2025 🕙 Time: 10:00 AM to 12:00 Noon (UK Time) 📌 Location: Wellington House, East Road, Cambridge, CB1 1BH, United Kingdom ☎ Phone: +44 1223 451000 🌐 Format: Hybrid (in-person & remote via Microsoft Teams) 💡 Cost: Free (registration required - https://forms.gle/upzLGyWJbRnbgRzU7 ) After a successful SVALint session in Reading, UK, we’re bringing this discussion to Cambridge—one of the UK’s most active semiconductor hubs. This event is geared toward engineers working in UVM based verification, formal verification, and testbench architecture using UVM and SVA. Ag...
Read more

SVALint Technical Meetup – Reading, UK

SVALint Technical Meetup – Hybrid Event in Reading, UK AsFigo invites engineers and verification professionals to a focused technical meetup on SVALint —an open-source static verification abstraction linting framework. The event takes place on Sunday, 8 June 2025 , from 15:00 to 18:00 BST , hosted in a hybrid format (face-to-face and online). Register via:  https://forms.gle/qo8TBczXjNk62yAP6   Venue (In-Person) Meeting Room-5, First floor,  Novotel Reading Centre 25B Friar Street – RG1 1DP, Reading – United Kingdom T +44 (0) 1189 522 610 novotel.com/5432 Virtual Attendance Join via Microsoft Teams Why SVA Linting? SystemVerilog Assertions (SVA) play a critical role in ensuring correctness in complex verification environments. However, poorly structured assertions can hurt simulation performance, complicate debugging, or lead to ambiguous semantics. Linting SVAs helps catch such issues early—enforci...
Read more

Call for Collaboration: Seeking Public UVM Environments for Verilator 5.0+ Porting

The transition of SystemVerilog UVM environments to open-source simulators presents specific technical challenges. While Verilator 5.0+ has expanded support for various SystemVerilog constructs, the industry still lacks a documented and repeatable path for certain UVM-specific behaviors. In parallel, we aim to curate a public vault of UVM repositories that have been successfully ported to Verilator. AsFigo is initiating a collaborative effort to document these gaps, and we are looking for engineers, researchers, and students to contribute original UVM codebases to this effort.  Link to Google Form: Submit Your code base The Technical Focus This effort intentionally moves beyond minimal or illustrative examples. We are seeking unique, original UVM implementations that reflect realistic UVM environments and non-trivial SystemVerilog usage found in real-world verification flows. Infrastructure Components: Memo...
Read more