This single character can provide shift-left in your coverage closure cycle - SystemVerilog dist, PySlint

In SystemVerilog based testbenches, functional coverage models and constraint models are like the yin and yang. 


In a good testbench, coverage model should specify what-to-observe using coverpoints/bins/crosses. An accompanying transaction model would capture transaction attributes along with constraints on variables and their relationships. This is specifically applicable to the input/stimuli-based coverage models. As part of coverage closure cycle, verification engineers run the random generator multiple times and measure the progress using coverage metrics. At times this cycle takes far too long and one of the possible causes could be wrong coding/models to begin with. It can be too-wide a state-space modeled using coverage constructs or too tight a constraint model (over constrained). Using static analysis one can identify a set of issues in coverage model and/or constraint model. Let's take a  case study of a wrong constraint model as shown below:

class data;
  rand bit [15:0] field1;
  constraint c_f1 { field1 dist {[0:31] := 1, [32:65535] := 1};}
endclass

(This example is picked from https://stackoverflow.com/questions/70438473/systemverilog-dist-constraint). Syntactically the above code looks just fine. However, as the user found (by running simulations many times):

 I'm trying to get an equal weight between two ranges [0:31] and [32:65535]. However, I'm seeing most values > 32. What have I misunderstood here?

 Plotting this as distribution, roughly one could visualize as below - while the user wanted a uniform distribution of values, some skewed behavior was observed.


Jumping guns, let's see what PySlint can tell us about this code:


PySlint: Violation: [FUNC_CNST_DIST_COL_EQ]: Potentially incorrect constraint expression! An expression involving dist ColonEquals is found, and the range used with ColonEquals is large. This is likely to skew the random generation and prevent other values in the dist expression to be generated less-frequently than the large range values Review to check if you intended to use ColonSlash instead of ColonEquals

 

field1 dist {[0:31] := 1, [32:65535] := 1}

So, PySlint flags a potential issue - a mix-up of ColonEquals vs. ColonSlash operator in SystemVerilog distribution constraint. Below is an extract from IEEE 1800 SystemVerilog LRM:


So, in a nutshell, when the range is large (say more than 10), using ColonEquals in dist can lead to skewed results in randomization and most likely user's intention would have been to have more spread about distribution as below:


But as the user in that StackOverFlow post/thread realized, such subtle coding issues can lead to loss of productivity. Imagine the same being used in a larger IP such as PCIe, USB etc. - this can have significant impact on coverage closure cycle due to a subtle mix-up of ColonEQ vs. ColonSlash. So, when in doubt - do not beat your random generator to death, instead get innovative and look for static code analysis such as PySlint!








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