Value of UVMLint - an anecdote from Race Conditions in UVM BCL code

Race conditions are one of the dreaded aspects of Verilog/SystemVerilog. Race conditions in SystemVerilog  lead to unpredictable behavior due to competing threads or processes accessing shared resources without proper synchronization. Debugging race conditions is challenging due to their non-deterministic nature, which means issues may appear sporadically and be hard to reproduce, complicating the identification and resolution of the underlying problem. It gets compounded by the fact that different EDA tools can behave differently on your code (with race condition) and yet be 100% LRM compliant (meaning no one will fix it for you). 

Would you believe that up until recently, UVM Base Class Library (BCL) had potential race conditions deep inside? Hard to believe? See for yourself a report from IEEE 1800.2 UVM core team members: 08376: 'static const xx ' class members with initialization - Accellera Mantis (mantishub.io)


Understanding Race Conditions in UVM: Why Switching from static const to localparam Matters

 The problem stems from how static const variables are initialized in SystemVerilog. If you're working with UVM or SystemVerilog, it's crucial to understand how variable initialization timing can impact simulation behavior—especially when using static const.

The Issue: Timing of Initialization

In SystemVerilog, static class members are shared across all instances and are typically initialized at runtime (LRM 1800-2017, §8.8.2). However, the exact timing of this initialization isn't guaranteed (LRM §6.24). For example, if you declare a static const string and try to use it early in your simulation, there's a risk that it hasn't been initialized yet. This is what we call a race condition: the code runs, but the initialization hasn't finished, leading to undefined or incorrect behavior.

The Fix: Using localparam

A better solution in this case is to use localparam instead of static const. Why? Because localparam variables are initialized at elaboration time (LRM §6.20), before the simulation even starts. This guarantees that the variable is ready and initialized when your simulation begins, avoiding any race conditions.

In SystemVerilog, localparam inside a class is not initialized at runtime, unlike static class members. Even when declared inside a class, localparam is initialized during elaboration, which happens before the simulation starts. This is an important distinction from static members, which are initialized at runtime. Below is an extract from the LRM on const:

So, in a nutshell:

  • localparam in a class: Initialized at elaboration, even if declared inside a class.
  • static const in a class: Initialized during runtime, when the class is first used or loaded into memory.

    • Using UVMLint to flag such issues:

    Given the hard work put in by the IEEE 1800.2 core team members to spot such issues manually earlier, our team at AsFigo got together and explored adding custom lint rules to identify any such issues across code base. This is crucial due to 2 key reasons:
    • Are there more such code segments within IEEE UVM BCL?
    • How do i prevent such code from creeping in going forward?

    This is where UVMLint comes in very handy - especially custom lint (or as we would like to call it -BYOL: Build Your Own Linter) - we used PySlint as framework and built rules for this and other issues and our findings are below:


    We are humbled to have been able to find this automatically and serve the industry that largely uses UVM on daily basis. We would be thrilled to see how our team can build similar custom linters for you, contact us via https://www.asfigo.com today! 
     


    Comments

    Post a Comment

    Popular posts from this blog

    Don't go "wild" with Associative arrays in SystemVerilog - PySlint it!

    Image
     Hash tables, modeled via Associative arrays is a powerful data structure in SystemVerilog. Python calls it as "dictionary". One of the "wild" features of SystemVerilog is that it allows associative arrays to be declared with arbitrary key type. An example:           class wild_c;             string wild_hash_table [*];           endclass : wild_c While the above is a legal SystemVerilog code, may even be seen as "easier" to write, it is bad from a reuse perspective. Some of the side effects (mostly bad) are: Unclear data structure to begin with - for writer and then the reader/maintainer of the code.  As the key can be anything, SV does not allow wildcard indexed associative array to be iterated via foreach loop. It cannot be passed as function parameter. Many find*  methods do not work on wild-card indexed associative arrays. For instance, find_first would need to return a queue of the keys, and when used on wild-card indexed array, it would be a queue o
    Read more

    Porting a complete UVC to Verilator + UVM - an anecdote!

    Image
     So, here we are on Day-1 of UVM + Verilator becoming available to the public, start of democratizing chip design verification. In case you just woke-up/started on this topic, read the release of UVM + Verilator with some intricate details on the challenge on the way by Antmicro via:  https://antmicro.com/blog/2023/10/running-simple-uvm-testbenches-in-verilator/  Awesome work by the folks at Antmicro and fantastic support by the ecosystem specifically Western Digital, kudos!  At AsFigo , we are committed to fueling open-source driven chip design and verification. So we took this opportunity to port a commercial-grade UVC (Universal Verification Component or a Verification IP) and ported it to compile and run on Verilator. Below are our reflections from this experiment. Get in touch with us to discuss how AsFigo can help your VIPs and testbenches to be ported to opensource EDA.  Case study: VLBus - a simple peripheral bus intended for write/read to configuration registers (like the pop
    Read more

    Opensource testbench generator for VHDL designs, OSVVM included!

    Image
    VHDL holds a prominent position in the world of FPGA design, particularly within the military, aerospace, and defense sectors. It serves both as a Register Transfer Level (RTL) design language and as a tool for creating testbenches. The availability of open-source simulators, such as GHDL and NVC, alongside numerous free FPGA simulators and synthesis tools, has provided FPGA designers with a significant advantage over their SystemVerilog counterparts. While the Universal Verification Methodology (UVM) is widely adopted among SystemVerilog users, VHDL practitioners have traditionally relied on various homegrown methodologies and frameworks. Recently, however, off-the-shelf methodologies and frameworks such as OSVVM, UVVM, and VUnit have become available to VHDL users. Each of these options presents different levels of complexity, allowing users to choose the one that best meets their needs. Despite these advancements, the development of open-source utility tools supporting the latest me
    Read more