A Functional Verification Framework Spanning Simulation to Emulation

Software engineers and firmware designers can find bugs, update their code and re-distribute to the users. In the consumer electronics world this means that my smart phone apps get updated, and my Android OS gets updated on a somewhat regular basis, however on the hardware side the design and verification of an SoC must be close to perfect, because there’s no easy way to do a field upgrade and the cost of a product recall can put your company out of business. Performing functional verification on an SoC is the focus of my blog today, and there are several tasks required during the verification process:

Our semiconductor industry has created and adopted the UVM (Universal Verification Methodology) as a standardized approach that can improve electronic product quality during verification. A SystemVerilog simulator used during verification can run maybe 10-1,000 clock cycles per second, depending on the block size and at that speed it just isn’t fast enough to boot an operating system, or paint a screen with pixels.

Related – Coverage Driven Analog Verification

In typical fashion, where there’s a need, there’s often a product to meet that need, and for chip designers there are emulators which can run a few million clock cycles per second, allowing us to boot an operating system and fill a screen. The initial usage of UVM was focused on SystemVerilog simulators, so what about writing UVM testbenches that can also run on emulators?

Anoop Saha of Mentor Graphics wrote a detailed, 16 page white paper on this topic: From Simulation to Emulation – A Fully Reusable UVM Framework, and you may download it online. The idea is that verification engineers should be able to run tests in both a SystemVerilog simulator or emulator, support SystemVerilog in emulation, and provide faster test results in emulation than simulation.

To make your testbench compatible with an emulator use two components:

• An HDL (Hardware Description Language) static component with DUT (Device Under Test), which runs on the emulator
• The dynamic testbench running on the simulator, which contains the HVL (Hardware Verification Language) behavioral code

Here’s what these two blocks look like where yellow is the HVL, blue is the HDL, and green is the top-level:

The interaction between HVL and HDL can further be refined by using a virtual interface construct where testbench components access SystemVerilog interfaces through a BFM (Bus Functional Model) interface. Shared parameters between HVL and HDL are defined in a common params_pkg file:

The HVL code is strictly untimed in this approach because that would not work with emulation and slow down emulation. If you really need delays in a testbench then add them only inside of an HVL to HDL function call.

Related – Improving Verification by Combining Emulation with ABV

To keep the communication minimal between HVL and HDL we use a transaction level only, where testbench objects on the left-hand side use a virtual interface handle to access signals in the HDL on the right-hand side.

Testbench components on the HVL side can:

• Call tasks and functions inside the BFMs
• Drive and sample DUT signals
• Start BFM threads
• Configure BFM parameters
• Read BFM status

Transaction-level modeling allows communication in both directions between HVL and HDL:

Make sure that all of your function arguments are synthesizable to enable this two-way communication.

Transaction objects can use dynamic arrays or queues, so that you can model activity like Ethernet transactions. Streaming communication is accomplished through SCE-MI (Standard Co-Emulation Modeling Interface) pipes, where receiving and sending are running independent threads. Here’s an example of a SCE-MI pipe operation where the HVL sends a whole packet, then the HDL receives that across multiple clock cycles.

It is now possible to reuse a UVM testbench across both simulation and emulation by following the methodology of:

• Creating an untimed HVL testbench, and a timed HDL with the DUT and BFM logic
• The untimed HVL code has no delays
• HDL code must be synthesizable as defined by the emulator platform
• Remote function calls are used to communicate between HVL and HDL, no direct HDL signals called from any HVL class

Emulation is attractive because of its high speed, providing speed improvements over pure simulation by 50 to 5,000X. By using this approach you gain the verification benefits of using an emulator in simulation acceleration mode:

• Includes assertions
• Functional coverage
• Power aware
• Replay-based debug
• Reporting
• Profiling

The complete 16 page white paper, including coding examples is online now.

Share this post via:

• 
• 
• 
•