SystemVerilog-VHDL-SystemC Verification IP Reuse Methodology

 
Abstract

The growing complexity of SoCs and the reduced life cycle of electronic products demand higher levels of design productivity while meeting compressed development schedules. The reuse of design IP components is critical to this mission. Industry experts concur that the verification effort is almost 70 percent of the overall design effort. With such a large percentage of a project's resources devoted to verification, design teams must also focus on verification IP (VIP). However, VIP alone does not increase verification productivity significantly; it must be accompanied by a methodology to facilitate reuse to the maximum extent under varying design IP configurations. As a growing number of design IP cores written in different languages are being integrated into a single chip, VIP reuse needs to be taken to new heights through a new verification methodology that breaks the barrier between languages by supporting design IP written in the same and different languages. This will broaden the scope of verification by extending the powerful verification features of SystemVerilog to VHDL and SystemC. Further, it is critical that the methodology support the reuse of VIP components.

This paper proposes a methodology that makes use of the SystemVerilog bind construct to achieve this. The proposed methodology will help verification engineers unleash the full potential of their VIP by not only allowing it to be comprised of elements written in different languages, but also allowing it to be reused in a mixed-language environment to verify design IPs written in different languages.


I. OVERVIEW

With the convergence of more applications offering more features on consumer products, system-on-chip (SoC) verification is becoming more complex than ever. The reuse of components cannot be ignored for this mission. Feasible reuse of IP cores requires that vendors must invest in a solid methodology for dealing with the verification challenges associated with rapidly changing and widely varying IP configurations. Verification IP (VIP) reuse plays a key role in overcoming the verification and quality issues that loom as a salient barrier to IP reuse today. Embracing verification reuse is essential to bringing customers and vendors one step closer to realizing the substantial benefits of IP reuse.

Experts concur that verification is almost 70 percent of the overall design effort. If verification is up to 70 percent of the challenge, and users are primarily focusing on design IP, then they are addressing only an element of the problem. With such a large percentage of a project’s resources devoted to verification, design teams must focus on VIP reuse. Put another way, design teams must look at the problem of IP reuse as a whole and include all its aspects when looking for a solution. Design, verification, timing closure, and test all play a significant part in the adoption and integration of a piece of IP. Designers often make the mistake of focusing solely on design IP when there are larger issues, like verification, that must be addressed to really achieve the benefits of reuse. Verification productivity and efficiency will not show any significant increase unless both VIP reuse and design IP reuse go hand in hand.

There are two aspects to VIP reuse: VIP component reuse and VIP reuse across multiple design IP cores.

A. VIP Component Reuse
Since each language has its own strengths and weaknesses, it may be appropriate to write the different components of VIP in different languages. Further, the diversity of design teams implementing IP from third-party IP vendors may contribute towards a mixed-language scenario. But for VIP to be successful, all of its individual components must communicate with each other.

 
Figure 1: Verification Environment Architecture

For example, pre-existing driver and monitors connected to a design under test (DUT) written in, for example VHDL,  can be in SystemVerilog, using synthesizable constructs like interfaces, modports, tasks, packed structs, etc. Communication is required between the different levels of the testbench, which is enabled by a data transfer mechanism and a synchronization mechanism between the languages. Therefore the methodology must allow the seamless reuse of VIP components written in different languages.

B. VIP Reuse across Multiple Design IP Cores

 
Figure 2: VIP Reuse across Multiple Design IP Cores


In the attempt to improve productivity, a growing number of design IP cores, often written in different languages, are integrated into a single chip. VIP reuse can be taken to new heights if the verification methodology can break the language barrier by not only supporting design IP written in the same language but also working across language boundaries. This will broaden the scope of verification by extending the powerful verification features of SystemVerilog to VHDL and SystemC.

The importance of increasing the productivity, as well as the predictability, of verification presents several compelling reasons for reusing VIP. This paper introduces a methodology to show how to do this. With the presented approach, verification engineers will be able to not only conveniently extend SystemVerilog assertions (SVA), cover groups, and constrained random testing to reuse VIP components, but also reuse VIP to verify their design IP written in different languages.

II. SYSTEMVERILOG - THE LANGUAGE OF CHOICE FOR VIP

A pure VHDL IP verification flow provides a coherent environment for design and verification but has limited testbench automation capabilities, lacks random constrained-stimulus generation, offers inefficient coverage models, and has no temporal assertions. This promotes a directed test based verification methodology, resulting in low performance and anemic bug finding effectiveness.

A pure SystemC IP Verification flow provides a reliable environment for design and verification but also lacks advanced testbench capabilities, such as functional coverage and temporal assertions. This leads to redundant testing effort, reduced performance, and low productivity.

The advanced, unified SystemVerilog HDL provides new and powerful verification constructs for validating systems at a high level of abstraction. SystemVerilog combines the best features of both VHDL and Verilog along with a rich set of verification features (such as temporal assertions, random constraints, cover-groups, classes, and binds) that are not available with either of these languages. This makes SystemVerilog the language of choice for a majority of verification engineers writing VIP. VIP written in SystemVerilog inherently supports interoperability and reuse because it is written in an established, standard, design and verification language.

But for a VIP that is not created from scratch, the effort required to translate and debug working VHDL/SystemC components into SystemVerilog may not be worth the investment. Hence, an efficient and hybrid design methodology that can co-exist with present VHDL/SystemC components must be adopted to develop these VIP, which are continually increasing in size and complexity.

III. THE METHODOLOGY

The crucial factor deciding the success of a methodology is ease of adoption and flexibility. The proposed methodology must enable users to easily attach SystemVerilog to existing VHDL/SystemC components without going into the nitty-gritty of the VHDL/SystemC language. Such a connection is possible using the SystemVerilog bind construct, which gives modules and program blocks access to not only the external ports but also the internal signals in the bound VHDL/SystemC VIP component or design IP. This is a powerful capability that, together with a specifically designed use-model, can be used to conveniently verify VHDL/SystemC design IP using the advanced verification features of the SystemVerilog language and enable reuse of VIP components written in different languages.

VIP component reuse is possible with the following 3-step use-model.
 
(1) Identify the SystemVerilog component and VHDL/SystemC component that need to be connected.

(2) Develop a wrapper module or program block to bind the SystemVerilog component of VIP to a SystemC/VHDL component.

(3) Instantiate this bind wrapper inside the VIP to load it automatically in the simulator.

VIP reuse across multiple design IP blocks is possible by following the following 3-step use-model.
 
(1) Identify the suitable VIP for verifying a SystemVerilog/SystemC/VHDL design IP.

(2) Develop a wrapper module or program block to bind this VIP to the SystemVerilog/SystemC/VHDL design IP.

(3) Load the above wrapper module, along with other top-level modules, into the simulator.

This proposed methodology can be used to extend SVA and functional coverage to SystemC and VHDL and extend random constraints to VHDL.

Reusing VIP Building Blocks
The rich set of SystemVerilog testbench automation capabilities, native assertions, random constrained-stimulus generation, and efficient coverage models are considered the building blocks of VIP.

The following sections explain how these building blocks can be reused.

A. SystemVerilog Assertions
SVA allows sophisticated, multi-cycle functional checks to be embedded in Verilog code as a powerful aid to design verification. SVA enables simple Verilog Boolean expressions to be built into complex definitions of design behavior, which can be used for verification, functional coverage, and both static and dynamic formal verification. Using SVA to verify VHDL and SystemC design IP has numerous benefits. It requires less assertion code, yet it does not require special interfaces. It interacts with Verilog and C functions, is easy to adopt, improves verification performance, increases productivity, enhances debugging, and is highly customizable.

Example: Connecting a SystemC Monitor to a SystemVerilog Data Integrity Checker
SystemVerilog Data Integrity Checker
program pxCheckDataInteg(input a, b, c, …);
  …
  assert property (@(posedge a) b |-> ##[1:2] c );
  …
endprogram

Binding a SystemVerilog Data Integrity Checker to a SystemC Monitor
bind SystemCMonitor pxCheckDataInteg checkerInst(.a(x),.b(y),.c(z),…);

B. Random Constraints
SystemVerilog constraint-driven test generation allows users to automatically generate tests for functional verification. Random testing can be more effective than the traditional, directed testing approach used by VHDL-based testbenches. SystemVerilog allows users to specify constraints in a compact, declarative way. These constraints are then processed by a solver that generates random values that meet the constraints. By specifying constraints, one can easily create tests that can find hard-to-reach corner cases in VHDL and SystemC design IP.

Example: Connecting a SystemVerilog Sequencer to a VHDL Driver

SystemVerilog Sequencer

module pxSequencer(
  input bit clk,
  output col_t pxi[N],
  input col_t pxo[N]);

  class col_test extends col_c;
    function new(int i);
      super.new(i);
    endfunction
    task main;
      forever @(posedge clk) begin
    assert(col_r.randomize)
    else $fatal(0," randomize failed");
    pxi[channel] =
           col_t'{col_r.R,col_r.G,col_r.B};
      end
    endtask : main
  endclass
   
  col_test col_f[N];

  initial begin
    col_f[0]=new(i);
    ...
  end

endmodule

Binding a Sequencer to a VHDL Driver
bind vhdlDriver pxSequencer sequencerInst(.a(x),.b(y),.c(z));

C. Functional Coverage
Functional verification comprises a large portion of the resources required to design and validate a complex system. To minimize redundant effort, coverage is used as a guide for directing verification resources by identifying tested and untested portions of the design. SystemVerilog coverage models can be used to measure whether interesting scenarios, corner cases, specification invariants, or other applicable VHDL and SystemC design conditions—captured as features of the test plan—have been observed, validated, and tested. It has been widely accepted that coverage-based verification can significantly increase the productivity, as well as the predictability, of verification.

Example: Connecting a SystemVerilog Coverage Collector to a SystemC Sequencer
SystemVerilog Coverage Collector
module pxCoverageCollect(…)
  …
  covergroup sm_cvg @(posedge clk);
    coverpoint int_state
    {
      bins idle_bin ={idle};
      bins load_bins =
             {load_bypass,load0,load9,load10};
      bins send_bins =
             {send_bypass,send0,send9, send10};
      bins others = {wait_idle};
      option.at_least= 500;
    }
    coverpoint in_hs;
    in_hsXint_state: cross in_hs, int_state;
  endgroup
 
  sm_cvg sm_cvg_
  …
endmodule

Binding a SystemVerilog Coverage Collector to a SystemC Sequencer
bind SystemCSequencer pxCoverageCollect
coverageCollectInst(…);

IV. INTERFACING VIA METHOD CALLS

SystemC and SystemVerilog allow methods to be used to describe the components in terms of abstract operations between the functional units. Such models simulate orders of magnitude faster than traditional RTL models. Not modeling the functionality of each individual hardware signal, but instead operating on abstract data types (possibly representing many individual signals), speeds up simulation substantially.

The SystemVerilog Direct Programming Interface (DPI) can be used for connecting a SystemVerilog verification component to a SystemC verification component using method ports. The DPI enables direct calling of SystemC functions from SystemVerilog, and vice versa.

As an example, consider a SystemC Stimulus Generator and a SystemVerilog Protocol Checker.

SystemC Stimulus Generator:
sc_module (sc_stimgen) {
...
    return_status gen_stim(void);
...
};

This method can be imported in the SystemVerilog Protocol Checker using the DPI import construct.

Importing the SystemC Method ‘gen_stim’ in  SystemVerilog:
import “DPI” function return_status gen_stim();

Once imported, this method can be used in SystemVerilog Protocol Checker to instruct SystemC Stimulus Generator to generate a new stimulus for the DUT.

V. INCREASING REUSABILITY ABSTRACTION

Transaction level models use methods, which are essentially software function calls, to model the communication between blocks in a system. This is in contrast to hardware RTL and gate level models, which use signals to model the communication between blocks. The scope of VIP integration and reuse can be increased significantly by supporting different levels of abstraction in the first layer of VIP that links with the DUT, which includes:

• Drivers and bus functional models for driving inputs to the DUT.
• Monitors for monitoring DUT activity.

This will allow it to be used with DUTs written in different languages at different levels of abstraction.

For example, if a VIP contains a driver that can be configured to work at both the RTL and transaction level, the whole VIP can be used with an RTL DUT as well as a transaction-level DUT.
 

Figure 3: Supporting Multiple Abstractions

The illustration above shows a driver that consists of both the RTL and TLM interface architectures. On one side of the driver is the interface to the stimulus generator that is always at the register transfer level. This interface is used to pass the stimulus generated by the stimulus generator to the layers under it. The other side of the driver is connected to the DUT interface. The TLM driver has probes and special logic to convert the signal-level activity to transactions.

VI. CONCLUSION

Experts state that the verification effort is almost 70 percent of the overall design effort. With such a large percentage of a project’s resources devoted to verification, verification IP reuse is an absolute must to meet today’s design verification challenges. With continuing proof from real-world designs that assertions, constrained-random tests, and coverage-driven verification reduce design cycles, improve productivity, and increase predictability and quality, it is not a surprise that designers want to write their VIP in SystemVerilog and use it to verify their VHDL and SystemC design IP. Verification engineers may also wish to reuse VHDL/SystemC components while developing their Verification IP in SystemVerilog. The proposed methodology makes it very easy and straightforward for them to do this.

VII. REFERENCES

[1] SystemC LRM IEEE 1666-2005 ()
[2] SystemVerilog LRM IEEE 1800-2005 ()
[3] VHDL LRM IEEE 1076-2002 ()
[4] Rudra Mukherjee et al, “SystemVerilog-VHDL Mixed Design Reuse Methodology”, DVCon 2006
[5] Arnab Saha et al, “Inter Language Function Calls Between SystemC and SystemVerilog”, DVCon 2007