Verification Learns a New Language

Abraham Lincoln once said, “What is conservatism? Is it not adherence to the old and tried, against the new and untried?”

By that definition, we engineers are a conservative lot. When I started in engineering in the 80’s I knew an engineering manager who decried the switch to cad software from paper drafting. “It will take us five weeks to design, ten if you make us use CAD.”

Not soon after that transition had happened the move from drawing circuits to writing RTL. Once again engineers were forced to give up the “tried and true” for the “new and untried.” 

The move to RTL created a language war between Verilog and VHDL. Regardless of which side engineers landed on, most of them used their RTL language as a testbench language. This led to advances in VHDL and the extension of Verilog into SystemVerilog. And that led to the creation of the UVM in SystemVerilog and UVVM in VHDL.

Seeing the big picture

The problem with incrementalism and the tried and true is that we sometimes spend so much energy looking at the next step in front of us that we don’t look up and see where we really want to be going. 

If we look at a proxy-driven testbench, that is a testbench in which a proxy provides function calls that control the BFMs, we see something like this:

This testbench has software that creates stimulus, checks results, and populates coverage. Today, because of incrementalism, many engineers write that software in SystemVerilog or VHDL. But one has to ask, “Why are we writing software with the notion of running it in a simulator? It’s not really simulating anything, the RTL is doing that.”

Once we ask that question we realize that we’d be a lot better off writing software in a software language. Which software language? The most popular language in the land: Python¹.

Proxy-driven testbenches written in Python could take advantage of the broad Python ecosystem of modules. Python verification teams could hire from a broader talent base, including newly minted college graduates. It would also be easier to create testbenches for complex applications such as machine learning.

Of course, this raises an immediate question. We all know how our SystemVerilog testbenches communicate with the BFMs because SystemVerilog defines interfaces that do that work. How does Python talk to a BFM?

One approach is through programming interfaces such as VPI for SystemVerilog and VHPI for VHDL. And so in the next blog post in this three-post series we’ll turn to an open source Python solution: cocotb

––––––––––––––––––––––––––––––––

¹ According to IEEE.