Use of "extern" methods in Verification IPs - a PySlint case study

As we prepare for Verification Futures 2023, Austin event, an enthusiastic user ran PySlint on a small SPI VIP and found the following violation (among others).


As expected, first reaction from the user was - what's the big deal?


Below is our attempt in rationalizing why this rule is important especially for VIP developers and users. 

A quick recap - The extern keyword in SystemVerilog is an optional qualifier to class methods. As in C++, Java and other languages, this is a highly recommended coding style, some benefits include:

  • Improves readability - By declaring the method prototype in one place and the implementation in another, it can be easier to "read" the code for end users (not only the original developers) - to quickly glance the list of APIs/methods without scrolling 1000s of lines of code (if the implementation is mixed with declaration). 
  • To hide implementation details. If the method implementation is defined in a separate file, it can be hidden from users of the class. This can be useful for security reasons or to prevent users from modifying the implementation. Many-a-times VIP code is shipped as encrypted, yet users need to know the API definitions/signatures. SystemVerilog extern aids here perfectly.
  • Enhances maintainability - Developers will know what is changing - the API signature or the "body". 
  • Distributed development - managers can distribute complex VIP code such as PCIe driver across few team members, as extern methods can be implemented in separate files. 
  • Allows for separate compilation. If the method is defined in a separate file, it can be compiled independently of the rest of the code. This can be very handy for large projects. 
Learn more about how you can code your own rules, customize existing ones with PySlint - https://github.com/asfigo/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