Posts

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...
Post a Comment
Read more

Technical Meetup: Open Source Chip Design and Verification, Jan 9, Hyderabad

Technical Meetup: Open Source Chip Design and Verification AsFigo is hosting a technical session dedicated to the advancements in open-source hardware design and verification.  Register for the Event   Please use the following MS Teams link to join the event on January 9th at 2 PM: https://teams.live.com/meet/9333303774354?p=bVhyGy7i3BGuUuiqpX This session is designed for engineers and practitioners looking to integrate modern automation and open-source methodologies into their silicon workflows. The discussion will center on the practical application of GenAI in hardware development, alongside a deep dive into specialized linting tools including SVALint, FPGALint, and UVMLint. Event Details Date: Friday, January 9th, 2026 Time:  2:00 PM – 5:00 PM IST Format: Hybrid (In-person and Remote) Venue:    Seminar Hall/Room No. EL-106, Centre for Advanced Studies in Electroni...
Post a Comment
Read more

Gain performance with your DPI - understand nuances of SystemVerilog DPI Pure Functions

Is your DPI-enabled SystemVerilog simulation running slow? Are you looking for ways to improve performance? Sometimes, a small remodelling of your DPI functions and using pure functions can help significantly. The Direct Programming Interface (DPI) allows SystemVerilog to interact with C code. Among the DPI constructs, pure functions are special because they are side-effect free and predictable. Using them correctly can improve simulation speed and reliability. However, SystemVerilog LRM imposes several subtle restrictions on imported pure  functions. Let's delve into one such nuance today a bit deeper! Referential Transparency Referential transparency is a concept from programming. An expression is referentially transparent if it can always be replaced by its value without changing the behaviour of the program. For example: The expression 2 + 3 can always be replaced with 5 . The expression rand() cannot, since each call may give a different result. In SystemVer...
Post a Comment
Read more

Clear, Correct, and Traceable: SPI SVA Best Practices

Ensuring Correctness and Observability in SPI Signal Assertions In SPI verification, a fundamental requirement is that all active signals— SCLK , MOSI , and MISO —must be fully defined whenever chip-select is asserted . Any unknown or high-impedance state ( X or Z ) can compromise data integrity and lead to subtle bugs. SystemVerilog Assertions (SVA) offer a natural mechanism to codify this requirement. When applied thoughtfully, they enforce correctness and enhance diagnostic clarity. Clear, modular assertions make failures immediately understandable, particularly in larger testbenches, which aligns well with style-aware analysis tools. Issue 1: Functional Correctness A common misstep is to combine multiple signals in a single $isunknown call with a logical AND: // INCORRECT $isunknown(spiclk && mosi && miso) The problem: logical AND short-circuits evaluation, potentially masking unknown states. Example: spiclk = X, mosi = 0, miso = 1 spiclk ...
Post a Comment
Read more

Catching Extra Semicolons After UVM Macros with UVMLint

A solution‑first guide to preventing the classic dangling else error caused by UVM reporting macros. UVMLint Rule: No Trailing Semicolon After UVM Reporting Macros Define a lint rule that flags any UVM reporting macro invocation immediately followed by a semicolon. Implementation detail: This rule should be parser‑aware . Avoid pure regex; require an AST/token stream so comments, strings, and macro line breaks are handled correctly. Why This Rule Exists Consider a simple user code as below:  // Buggy code if (debug_on) `uvm_info("DEBUG", "state info", UVM_LOW); // semicolon here else $display("Doing something else"); The UVM BCL defines  `uvm_info  as a  complete  begin...end  block . Adding a semicolon after the macro turns into a null statement that terminates the  if  prematurely, leaving the  else  orphaned. // UVM BCL (abridged) `define uvm_info(I...
Post a Comment
Read more

Why Regex-Based Linters Fall Short for SystemVerilog/UVM — A Case for Parser-Based Tools

Image
Linting SystemVerilog and UVM testbench code is crucial to maintain quality and compatibility. Many teams start by writing quick regex or string-search scripts to catch problematic patterns—like deprecated variables, disallowed constructs, or outdated API usage. While regex-based linting can be tempting due to its simplicity, it often leads to false failures and missed issues because SystemVerilog’s syntax and preprocessing are too complex for simple text matching. In this series, we will explore common linting scenarios, we introduced this in an earlier post here:   https://asfigo.blogspot.com/2025/02/linting-systemverilog-testbench-code.html  Below is the next one in this series with a concrete example - detecting deprecated UVM constructs like uvm_top , and demonstrate why a proper parser-based approach using tools like Google’s Verible is superior. A Quick, regex style lint example When maintaining UVM code for compatibility, one common check is to detect the use of u...
Post a Comment
Read more

From Guesswork to Metrics: Measuring Constraint Complexity in SystemVerilog (Part 1)

🚀 Why Care About Constraint Complexity? In SystemVerilog, constraint blocks are a core part of constrained-random verification. As your testbenches scale up, these blocks can become: Hard to read Difficult to debug Slow to solve Prone to over- or under-constraining Yet most teams rely on intuition or manual review to judge constraint quality. What if we could measure complexity more objectively? This is where Halstead Complexity Metrics come in. 📐 What Are Halstead Metrics? Originally developed by Maurice Halstead in the 1970s for software code analysis, these metrics: Count operators and operands Compute values like: Volume (how much information the code conveys) Difficulty (how hard it is to understand) Effort (how much mental work is required) Estimated bugs (how likely the code is to be error-prone) They’ve been applied in languages like C/C++, Java, and P...
Post a Comment
Read more