How do you verify your DUT thoroughly?

It’s not simple as you always assume and misguide others saying, ‘all you need is a great coding skill to write a testbench in SystemVerilog or UVM and the verification job is done’. Functional Verification process is much more than writing a complex testbench, though testbench is the major component. This figure shows various components needed to verify the DUT thoroughly.

Testbench[TB] / Verification Environment : Testbench is the main component which generates stimulus and verifies the DUT functionality, comparing the DUT outputs with expected values. In order to become a TB coding expert in SystemVerilog, one needs to focus on defining constraints and generating constraint random stimulus, creating testbench components using various language constructs smartly and making the testbench as self-checking TB using scoreboards. One needs to define a detailed verification plan that includes all the details, TB architecture, test scenarios, verification strategies, coverage model, etc., before writing the source code. Refer to the article: VIP vs TB

Coverage: In addition to testbench, one needs detailed coverage data that includes both Code & Functional coverage to track the simulation progress and sign-off the verification. We use code coverage to rate the quality of testcases and functional coverage to verify the DUT features. Refer to the articles:
Code Coverage,Functional Coverage

Assertions: In addition to coverage, one needs to write assertions to verify the DUT interface protocols, as the TB does only data integrity checking. Refer to the article: Why SVA?

In addition to TB coding, Coverage & Assertions, verification engineers should know how to use scripting languages like PERL or TCL or shell scripting to write scripts and automate the simulation flow. Most importantly, they really need to be good at RTL design concepts and HDL coding in order to debug the simulation failures and communicate the design issues confidently to the designer. As a verification expert, you really need to be good at finding bugs in the design and disproving the designer.

Just being a SystemVerilog coding expert doesn’t assure any ticket for you to become a verification engineer. Think beyond coding.

Related Posts