Verification

SystemVerilog Testbench/Verification Environment Architecture

SystemVerilog Testbench_Verification Environment Architecture

Most of the well-known SystemVerilog textbooks available in the market explain the language concepts focusing more on language constructs, keywords, datatypes, examples, etc., without following a proper testbench architecture and implementation guidelines. So, we can use them only as additional reference materials along with SystemVerilog Language Reference Manual [LRM].

What are we going to do with the SystemVerilog language? Design or Verification?

If Verification, then how can we use all the constructs to create a proper SystemVerilog testbench? How can we create a reusable testbench? How can we migrate the SystemVerilog testbench into an industry standard UVM testbench?

We need to know the answers for all these questions before choosing a textbook or training course to learn SystemVerilog [SV]. Testbench architecture is very important for a beginner to learn SV and write testbenches on his/her own. Eventually the engineer should be highly skilled to create a reusable testbench using SV language constructs. So, in this article I would like to explain a standard testbench architecture.

It follows the UVM testbench architecture style. Let me explain how it works.

  • Generator generates the transactions[Write/Read packets] and sends them to drivers.
  • For every interface[Write & Read], drivers and monitors are created.
  • Driver collects the transactions and drives them as binary values to DUT as per the DUT interface protocol[Write/Read protocol].
  • Monitors collect the binary values from the DUT pins and convert them back into transactions[Write/Read packets].
  • All the monitors are connected with the scoreboard which compares the DUT outputs with the expected values.
  • Scoreboard has a reference model and comparison logic. Reference model produces the expected value and comparison logic compares the DUT outputs with expected values.
  • Monitors post the transactions into the scoreboard.
  • Upon successful comparison, the scoreboard/subscriber produces functional coverage.
  • Testbench/verification environment creates the objects of all the transactors, generator, driver, monitor and scoreboard.
  • Base test will instantiate the testbench/environment class object and generate a default test scenario.
  • All the testcases use the base test to generate different kinds of test scenarios.

This is the testbench architecture I have created to teach SystemVerilog language concepts to young engineers who are new to SV. We have been using this testbench architecture for many years at Maven Silicon. We have trained 1000s of engineers and deployed them as verification experts in the semiconductor industry till date. Hope you will be the next one.

Exit mobile version