Python for RTL Verification is a book for verification engineers who want to use Python and Python engineers who want to learn the Universal Verification Methodology (UVM).
New applications such as machine learning are forcing verification engineers to develop new verification techniques and leverage broader ecosystems of libraries. As the most popular programming language on the planet, Python has the capacity and ecosystem to solve modern verification challenges. Testbench developers will either access Python libraries from SystemVerilog or VHDL or write their testbenches in Python.
This book teaches you how to write testbenches in Python. It teaches you enough Python to use the pyuvm and cocotb modules to create the next generation of testbenches.
The book assumes you know how to program
Python for RTL Verification assumes that the reader wants to add Python or the UVM to their existing programming skillset. A reader who knows Python can skip to the cocotb chapters, and a reader who knows cocotb can skip to the pyuvm chapters.
You can get a copy of the code examples in this book at pythonverification.com. There are two types of examples, Jupyter Notebook examples and directory examples. The Jupyter Notebook examples demonstrate the Python language. The directory examples are in directories demonstrate cocotb interacting with a simulator. We store these in directories. The instructions to run cocotb examples are also in README.md.
The example files and directories have the same names as the chapters, and the numbers at the beginning the names cause them to print in the same order as the book chapters when you list them alphabetically.
Each example has a figure number that matches the example in the book to the example in the code. The numbers reset each chapter. For example, figure 1 demonstrates the classic first program we write in all languages. It is in the file 00_lntroduction.ipynb.
All the book's code examples use the same format, a figure number and description, the code, then a line with a separator --, followed by the output.
# Figure 1: The classic first program
print("Hello, world.")
- -
Hello, world.
There is an urban legend that the width of the Space Shuttle’s solid rocket booster was determined by the width of a train tunnel it had to pass through on the way to the launch pad. That width was determined by the width of the train tracks, which was determined by the length of the axles, which was … etc. The story goes back and back until we get to the width of the ruts left by a Roman chariot. A similar story could be told about the languages most of us use to verify a design written in a register transfer language (RTL). SystemVerilog and VHDL testbenches are the product of decades of incrementalism.
The 1980s saw a revolution in digital design methodologies with the introduction of register transfer languages such as Verilog (created by Gateway Design Automation) and VHDL (created by a US Government military specification for documentation but leveraged to create synthesizable code -1).
We have argued whether VHDL or Verilog is the better hardware design language for thirty years. But one cannot claim that either of them was initially designed to create testbenches. Testbench development is a software problem not readily solved by hardware design languages. Several approaches have recognized and addressed the need for a testbench language.
In 1996, a startup named InSpec took the most obvious approach and announced an entirely new language named e . Explicitly designed for verification, e introduced the industry to object-oriented and aspect-oriented programming. It also championed what was then an advanced verification technique, constrained-random verification, implemented with a methodology called the e Reuse Methodology (eRM).
e gained popularity, but it was limited in its growth by its very newness. Teams that adopted e often needed considerable consulting help to create their first testbenches. The other problem was that e was proprietary to Verisity (the renamed InSpec). You needed to buy Verisity’s software, and only their software, to run an e testbench.
Three years later, another startup named Co-Design Automation announced SUPERLOG, which extended the standard Verilog language to provide verification-friendly concepts such as interfaces. Co-Design immediately put SUPERLOG into the public domain, intending to create an open ecosystem.
The competition between e and SUPERLOG tilted in SUPERLOG’s favor when Synopsys bought Co-Design. Synopsys donated its verification languages Vera and SUPERLOG to the Accellera standards body. Accellera created SystemVerilog by merging Vera, SUPERLOG, and the ForSpec assertion language.