AsFigo - enabling opensource chip design and verification.

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...

Universal Verification Methodology (UVM) stands as the pinnacle of design verification methodologies in the ASIC and FPGA domain. The integration of linting and static code analysis has emerged as a vital practice, particularly in projects with broad user bases, extended lifetimes, and distributed development teams. Recently, during the UVM IEEE 1800.2-2023 release cycle (at DVCon US 2024), the potential for a custom UVMLint solution to enhance the UVM Base Class Library (BCL) development process was recognized. Some of the lead developers of UVM BCL suggested to create a simple rule deck that focuses on specific issues seen by the core development team over last few years than a general-purpose linter that may end up throwing 1000s of violations.   At AsFigo, we've taken the initiative to develop custom linting rules tailored specifically for the UVM BCL. Our goal is to offer our community an open-source lint package that can be used by the UVM IEEE committee and the wider devel...

              As verification engineers – we believe strongly in Trust-but-Verify mindset. So, as part of our #UVMLint value finding, we decided to run it on official examples shipped along with Accellera/IEEE UVM libraries. One of the most referred examples from UVM library is APB UVC/agent code: Usually, the intention of such examples is to serve as “golden reference” for users to model their verification environments. However, no lint checks were done (at least officially/publicly) on such examples shipped with UVM so far – partly due to non-availability of such UVMLint solutions, partly due to lack of commonly agreed rules etc. So with the opensource PySlint was built by AsFigo during 2023, goal was to fill this void and democratize UVMLint to the wider user base. Fast forward – Feb 2024, we ran UVMLint on these examples and below is what we found: While we ran a subset of rules on this small VIP/UVC, we are thrilled by the findings from UVMLi...

Responding to a user query on: https://verificationacademy.com/forums/t/what-is-the-advantage-or-the-main-purpose-of-using-followed-by-operator-in-sva/45808/2  Followed-by operators were later added to the LRM (2009). Quoting from our SVA  handbook (Thanks Ben Cohen, Ajeetha Kumari & Lisa Piper)   the equivalence of sequence_expr #=# property_expr is:   not (sequence_expr |=> not property_expr) So fundamentally there is a difference - when the ANTECEDENT is false, implication treats it as "vacuous success" while the followed-by throws a failure. A good application is while writing cover on a property that was using |=> operator - your coverage results would mislead as "covered", whereas if you use followed-by operator, you would get exactly what you wanted! Below is a tiny example. module m;      bit clk, a, b;      default clocking dcb @(posedge clk);   endclocking : dcb      always #5 clk = ~clk...

 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...

 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 que...

 SystemVerilog is a vast language with long history. With any history, you have the problem of legacy - sometimes bad too, unfortunately. One such bad legacy is the use of "DPI" as spec-string in SystemVerilog Direct Programming Interface (DPI) code, used to interface C with SystemVerilog. It is a very commonly used feature in certain classes of systems as it allows reuse of reference models as-is in Design Verification. Jumping straight into a potential compatibility issue with DPI, historically Accellera SV (3.1a) allowed the following code: import "DPI" function int c_sum (int f1, f2);     However, as LRM matured and became an IEEE 1800 version, the above got refined to be "DPI-C". This is often referred to as "spec-string". Now, what's the big deal - one may ask, well below is a quote from IEEE 1800 LRM: So, if your old SV code was using "DPI" as spec-string, potentially: You have confusing 2-state, 4-state value passing across ...