SystemVerilog Testbench/Verification Environment Architecture | Maven Silicon Blog

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.

Originally published at on May 7, 2020.




Love podcasts or audiobooks? Learn on the go with our new app.

Recommended from Medium

9 Amazing Articles on Python Programming

Learning how to code: a self-learning journey

Archiving Analog Audio on a Raspberry Pi using Liquidsoap

A Beginner’s Guide to DBT (data build tool) — Part 4: DBT — Automation, Test and Templating

Ultra-fast way to install Jenkins server


Debezium with Simple Message Transformation (SMT)

Hello and Welcome to the Zola Games (ZOLA) Community

Get the Medium app

A button that says 'Download on the App Store', and if clicked it will lead you to the iOS App store
A button that says 'Get it on, Google Play', and if clicked it will lead you to the Google Play store
Maven Silicon

Maven Silicon

More from Medium

Publish to NuGet with GitHub actions

ELK (Elasticsearch, Kibana, Filebeat and Metricbeat kubernets) stack’s Automated Certificate…

Managing git with personal access tokens

Write GitHub Actions