SystemC Mixed-HDL IP Reuse Methodology

Rudra Mukherjee, Gaurav Kumar Verma, Arnab Saha
Questa/ModelSim Engineering, Mentor Graphics

Abstract

Due to increased complexity in today's embedded system designs, the importance of design reuse, verification, and debug becomes inescapable. Also, current mixed-language methodologies are not efficient enough to address the verification needs of today's competitive market, which is seeing more and more of these types of design. There is an urgent need to have an efficient SystemC-HDL cross-language methodology that breaks the language barriers and tightly integrates the different standards as one. This methodology will help designers reduce their verification process by using verification IP that is developed using a rich set of verification features and methodologies across multiple languages.

This paper proposes a methodology which addresses the clear needs of the ever-growing SystemC mixedlanguage designs by delivering critical capabilities, including advanced verification features such as; SystemVerilog Assertions (SVA), cover-groups, SystemC Verification (SCV), and more. Potential reusability issues are highlighted which require a careful mixed-language design process and planning.

I. INTRODUCTION

SystemC[1], SystemVerilog[2], and VHDL[3] have unique strengths which make them more suitable to certain application domains. SystemC mixed-language designs are proliferating because designers want to use the powerful features of SystemC for creating test benches for designs written in SystemVerilog or VHDL and because designers are importing VHDL or SystemVerilog intellectual property libraries to use with their SystemC designs. Designers may also wish to use the powerful verification features of SystemVerilog to create test bench for their designs written in SystemC. Either can be achieved by directly instantiating a SystemC module in VHDL or SystemVerilog, or vice versa.

This paper proposes a methodology which addresses the clear needs of SystemC mixed-language designs by delivering critical capabilities, including advanced verification features such as; SystemVerilog Assertions (SVA), cover-groups, SystemC Verification (SCV), and more. The proposed SystemC–HDL mixed-language design reuse techniques provide a bridge to formal verification and the ability to apply assertions across multiple design languages. This paper explains in detail how the proposed solution can be used to facilitate accurate and efficient use of designs (with ports of type record/struct, class, union, enum, multi-d array, and others) across the language boundaries. Potential reusability issues are highlighted which require a careful mixed-language design process and planning. Critical issues have been discussed, such as type checks, and state mapping while making direct port connections at the SystemC mixed-language boundary.

II. SYSTEMVERILOG AND SYSTEMC

The most important languages to emerge for advanced design, verification, and modeling are IEEE Std 1800 SystemVerilog with its advanced verification, modeling, and hardware design capabilities, and IEEE Std 1666 SystemC, with its powerful modeling features and tight links to the C/C++ programming languages. The challenge faced by many SoC teams is how to use these languages together for mixed-language, mixedabstraction level verification.

We will discuss using these two very capable languages for verification, system simulation, behavioral high-level synthesis, RTL design, and modeling.

SystemVerilog-SystemC Design Methodology

The proposed SV-SC design methodology not only overcomes various limitations of current mixed-language design methodologies but also extends the scope of IP integration and reuse. To achieve substantial productivity gains in current and future mixed-language design projects the designers and mixed-language EDA tools should

1. extend the type of reusability by directly reusing data types , subprograms, constants, etc., defined across language boundaries,
2. take IP reuse to higher levels of abstraction by
1. using complex user-defined and multidimensional ports at cross-HDL interfaces,
2. enhancing configurability and scalability using complex generics/parameters
3. maintain consistency across-HDLs using equivalent features.

Types of SV-SC Reusability

A. Data Types

With the introduction of new SystemVerilog (SV) data types, designers will be able to directly use the equivalent SystemC object model for SystemVerilog data types defined in packages, facilitated by the mixedlanguage design tools. Compatible SystemVerilog data types can be imported to define SystemC variables and constants.

Example: SystemVerilog data type import

SystemVerilog Package

package ethernet_ip_pack;
     typedef struct {
          bit [0:61] preamble;
          bit [0:47] dest_addr;
          bit [0:47] src_addr;
          bit [0:15] frame_type;
          bit [0:367] data;
          bit [0:31] crc;
     } ethernet_frame;
endpackage

SystemC Module

SC_IMPORT(ethernet_ip_pack);

//Data-Types imported from SV
ethernet_frame frame;

Tables 1 and 2 show compatible data types in SV and SystemC to assist designers and mixed-language design EDA tools relate cross-HDL data types.

Table 1: SV-SC Compatible Data Types

SystemVerilog Type	SystemC Type
bit, logic, reg, wire	bool, sc_bit, sc_logic
bit/logic/reg/wire vector	sc_bv , sc_lv, sc_int, sc_uint
[unsigned] integer/int	int [unsigned], vector of size 32
[unsigned] shortint	short [unsigned], vector of size 16
[unsigned] longint	long long [unsigned], vector of size 64
[unsigned] byte	char [unsigned], vector of size 8
real/shortreal	double/float
enum	enum
struct [packed/unpacked]	struct
union [packed/unpacked]	union
multi-d vector	array of signals*

Conversely, designers will be able to directly use the equivalent SystemVerilog object model for SystemC data types defined in header files, facilitated by the mixed-language design tools. Compatible SystemC data types can be imported to define SystemVerilog variables and constants.

Example: SystemC data type import

SystemC header file (sc_pack.h)

     typedef struct {
          sc_bv<62> preamble;
     sc_bv<48> dest_addr;
     sc_bv<48> src_addr;
     sc_bv<16> frame_type;
     sc_bv<368> data;
     sc_bv<32> crc;
     } ethernet_frame;

     typedef enum {
          IDLE, SEND, RECEIVE, FAILED
     } states;

SystemVerilog Module

import sc_ethernet_ip::*;

//Data Type imported from SC
input ethernet_frame in1;

Table 2: SC-SV Compatible Data Types

SystemC Type	SystemVerilog Type
bool, sc_bit, sc_logic	bit, logic, reg, wire
sc_bv<W>, sc_lv<W>	bit [W-1:0], logic [W-1:0]
[unsigned] short	shortint [unsigned], vector of size 16
[unsigned] int/long	int [unsigned], vector of size 32
[unsigned] long long	longint [unsigned], vector of size 64
sc_int<W>/sc_signed sc_uint<W>/sc_unsigned sc_bigint<W>/sc_biguint<W>	shortint [unsigned] (if W=16) int [unsigned] (if W=32) longint [unsigned] (if W=64) bit [W-1:0] (otherwise)
[unsigned] char	byte [unsigned], vector of size 8
double/float	real/shortreal
enum	enum
struct	struct [packed/unpacked]
union	union [packed/unpacked]
array of signals*	multi-d vector

* SystemC array of signals have no direct equivalent type in SystemVerilog. They, however, have a very close similarity with multi-d vectors. As such, SystemC signal arrays can be connected to compatible SystemVerilog multi-d vectors. A SystemC signal array of ‘N’ signals is compatible with a SystemVerilog unpacked array of size ‘N’. The packed dimension of the SystemVerilog array is one of the compatible types of the signal of SystemC signal array.

Example: Using SystemC Signal Array

SystemC Signal Array

SC_MODULE(cpu) {
sc_in<sc_bv<32> > sig1[16];
…
};

Instantiating CPU in SystemVerilog

typedef bit[0:31] mdarray[0:15];
marray sv_sig1;
cpu_inst cpu(.sig1(sv_sig1), …);

In SystemVerilog, an enum can be defined with any base type, but SystemC allows only enums to have a base type of int (32-bit, 2-state integer). As such, a SystemVerilog enum may be used at the SC-SV mixed-language boundary only if its base type is int.

Such compatible enums may be defined inside an SV package, or SystemC header file, which can be imported and used in the other language.

Example: Importing SV enum type

SystemVerilog Package

package sv_pack;
typedef enum{ idle, state1, state2,
     state3, state4 } state_t;
endpackage

SystemC Module

SC_IMPORT(sv_pack);

//Data-Types imported from SV
SC_MODULE(sc_inst) {
     sc_in<state_t> state;
     …
};

B. Classes

Support for classes at the SystemC-SystemVerilog mixed-language boundary allows coupling at a higher level of abstraction. This enables complex cross-HDL components to work together seamlessly, obviating any extra piece of code required to map SystemC, complex aggregate types to SystemVerilog scalar data types at interfaces. It also helps designers to partition complex designs at any logical boundary that makes best use of both languages.

Classes can form the basis for mixed-language transaction-level modeling. A class can represent a transactor with its methods transactions. The objectoriented features of classes are ideal for modeling at this level of abstraction. Support for mixed-language classes enables development of IP using the class based methodology.

A class may be defined inside a SystemVerilog package which can be imported by a SystemC module. Conversely, a class can be defined inside a SystemC header file which can be imported like a normal SV package by a SV module.

Since all SystemC class declarations must precisely correlate with classes declared in the SystemVerilog domain, a SystemC class must not use constructs that are not available in SystemVerilog. For example, SystemC classes with overloaded functions will not be allowed at the mixed-language boundary, as function overloading is not allowed in SystemVerilog.

Table 3 shows compatible class constructs in SV and SystemC to assist designers and mixed-language design EDA tools relate cross-HDL data types.

Table 3: Corresponding Class Constructs

SystemVerilog	SystemC
base class(extends)	base class(public)
virtual base class	virtual base class
class property	public data member
local class property	private data member
protected class property	protected data member
static class property	static data member
const class property	const data member
class method	public member functions
constructor(new)	constructor
static class method	static member function
parameterized classes	class template

Some SystemC class constructs (such as multiple inheritance, friend declarations, and copy constructors) do not have equivalent constructs in SystemVerilog and, hence, may not be allowed for classes crossing the language boundary.

Member functions and tasks of classes are handled the same way as normal functions and tasks, as described in section F.

Example: Using classes in mixed-language TLM

SystemVerilog Package

package pci_ip_pack;
class pci_master;
      …
      task pci_master_write(
           input bit [31:0] data,
           input bit [31:0] address,
           input bit [4:0] enable);
      task pci_master_read(…);
      …
endclass
endpackage

SystemC Module

SC_IMPORT(pci_ip_pack);
pci_master pci = new pci_master(…);
pci.pci_master_write(…);

Example: Importing SV class type

SystemVerilog Package
package sv_pack is
class C;
…
endclass
end sv_pack;

SystemC Module

SC_IMPORT(sv_pack);
SC_MODULE(sc_inst) {
sc_in<C> C_obj;
…
};

C. Events

The equivalent of an event in SystemVerilog is sc_event in SystemC. An event passed across the SystemCSystemVerilog interface follows the same semantics as used for passing regular data types. Passing an event leads to creation of an event in the other language. These two events point to the same underlying synchronization object, so triggering one will trigger its counterpart. As described in the SV LRM, assigning an SV event to the special value of NULL or to another event will break the link with the SystemC event.

Figure 1 illustrates the behavior of the new event created at the mixed-language boundary.

Figure 1: Events at the SC-SV language boundary

Example: Using events at SC-SV language boundary

//Consumer is connected to the producer via an
//event. Consumer triggers an event every time
//it is ready to consume a packet. This event
//triggers the event in the producer to
//dispatch a packet to the consumer.

SystemVerilog Module

module producer(input send_pkt, …);

SystemC Testbench

SC_MODULE(consumer) {
      sc_event ready_event;
      prod_inst = new producer(“prod_inst”);
      prod_inst->send_pkt(ready_event);
      …
};

D. Functions and Tasks

Functions declared in SystemC header files will be available for use directly in the SystemVerilog module.

Similarly, a function/task defined inside a SystemVerilog package will be available in the SystemC module.

The arguments of these functions and tasks will follow the same type compatibility/mapping conventions as followed by ports at the mixed-language boundary.

Example: SC function import

SystemC header file, sc_pack.h

int addInt(int a, int b) {
      return a + b;
}

SystemVerilog module

import sc_pack::*
module(…)
int a, b, sum;
…
sum = addInt(a, b);

E. Overloaded Operators

Both SystemC and SystemVerilog allow operator overloading. The need for operator overloading arises from the fact that the operators in the language are defined only for operands of some predefined type. Operator overloading can be used in conjunction with data-type import to allow the defined arithmetic operators to be applied to the imported data types, such as structures, unions, classes, and enumerations.

Example: SystemC Overloaded Operators Import

SystemVerilog

bind == function ethernet_frame comp_frames
(ethernet_frame, ethernet_frame);

SC Module

SC_IMPORT(ethernet_ip_pack);
ethernet_frame frame1, frame2;
…
// implicit call to overloaded SV “==” operator
if (frame1 == frame2) ...

III. VHDL AND SYSTEMC

Pre-defined language environments in the form of packages are available with all VHDL implementations.

Standard IEEE packages provide rich sets of data types and subprogram definitions that are heavily used across various VHDL design units. To reuse any subprogram or data type at the mixed-language boundary requires direct translation of VHDL packages by SystemC designers because there is not a reuse facility available in either the SystemC language standard or the supporting tools.

The close similarity of SystemC with C++ and the inbuilt flexibility of header files offer a unique opportunity for VHDL designers to import VHDL packages into the SystemC domain. SystemC includes statements that provide direct visibility of VHDL packages in the SystemC domain.

SC_IMPORT(vhdl_pack);
SC_IMPORT(std_logic_1164);

Reusing VHDL packages in the SystemC domain requires direct import of all user and pre-defined data types, functions/subprograms, resolution functions, overloaded operators and functions, constants, and enumeration literals.

Tables 4 and 5 show compatible data types in VHDL and SystemC to assist designers and mixed-language design EDA tools relate cross-HDL data types.

Table 4: VHDL-SC Compatible Data Types

VHDL Type	SystemC Type
std_logic, bit, boolean	sc_logic, sc_bit
std_logic_vector, bit_vector	sc_lv, sc_bv
real	double/float
integer	primitive C integer types
record	struct
enum	enum
multi-d array	array of signals*

Table 5: SC-VHDL Compatible Data Types

SystemC Type	VHDL Type
bool, sc_bit, sc_logic bit, std_logic, boolean
sc_bv, sc_lv, sc_bigint/sc_biguint	bit_vector, std_logic_vector
primitive C integer types	integer
sc_int/sc_signed sc_uint/sc_unsigned	integer (if W<32) bit_vector (otherwise)
enum	enum
char	character
struct	record
float/double	real
array of signal*	multi-d array

* SystemC array of signals have no direct equivalent type in VHDL. They, however, have a very close similarity with VHDL multidimensional arrays. As such, SystemC signal arrays can be connected to compatible VHDL multi-d arrays. A SystemC signal array will be compatible with an array of size ‘N’ of the VHDL type compatible with the element of the SystemC signal array.

Example: SC signal array at SC-VHDL boundary

SystemC Signal Array

SC_MODULE(cpu) {
      sc_in<sc_bv<32> > data_bus[16];
      …
};

Instantiating cpu in VHDL

type data_arr is array (0 to 15) of
bit_vector(0 to 31);
signal vh_data_bus : data_arr;
cpu_inst cpu(data_bus => vh_data_bus, …);

VHDL Procedures and Overloaded Functions Import

VHDL provides subprogram facilities in the form of both procedures and functions. SystemC extends all the functionality of C++ when it comes to support for functions. This allows reuse of VHDL procedures and functions in an efficient and intuitive manner. While calling VHDL subprograms with complex argument types from the SC side, VHDL equivalent SC data types can be specified as actual argument types to any of the argument types. To facilitate the use of output and inout ports in VHDL subprograms, these arguments must be passed by reference when the function is used in SystemC.

Example: SystemC using VHDL procedure.

VHDL Package

package vhdl_pack is
-- VHDL procedure declaration
procedure word_32_or (driver1, driver2 : in
word_32; en: in bit := '0'; or_out : out bit );
end vhdl_pack;

SC Module

SC_IMPORT(vhdl_pack);
...
void module_func() {
// function interface for VHDL subprogram call.
word_32_or(data1, data2, 1, &sum_or);
end

Both SystemC and VHDL allow overloaded functions. With package import it is possible to reuse VHDL overloaded functions in the mixed-language domain.

IV. EXTENDING SV ASSERTIONS TO SYSTEMC

SystemVerilog offers a rich set of testbench automation capabilities, native assertions, and functional coverage.

These features make SystemVerilog increasingly appealing to users who need to implement an efficient and effective functional verification methodology. These unique feature sets can be extended to SystemC using the SystemVerilog bind construct. Assertions can be included directly in the source code of the modules in which they apply. They can even be embedded in procedural code. Alternatively, verification code can be written in a separate program block and that program block can then be bound to a specific module or module instance. The SystemVerilog bind construct provides modules and program blocks access to both external ports and internal signals in the bound SystemC object. Among other things, this capability can be used to monitor SystemC functionality with SystemVerilog Assertions (SVA) or assess the functional coverage of SystemC designs.

Suppose the user wants to use SVA to monitor a SystemC module. To do this effectively, he or she will need SVA to access the module’s ports and internal signals without modifying the SystemC code. The procedure for binding SystemVerilog and SystemC includes:

A. Creating a SystemVerilog program or module to hold the verification code.

B. Developing a wrapper module or program block to bind the SystemVerilog code to the SystemC module.

C. Automatically loading multiple top-level modules into the simulator or instantiating the SystemVerilog bind wrapper.

For example, let’s take the following SystemC code:

SC_MODULE(cpu) {
    sc_in<sc_logic> clock;
    sc_in<sc_logic> flag;
    sc_signal<sc_logic> data;
    ...
}

Definition of the properties to be monitored using a SystemVerilog program:

program cpu_props(input d,e,f);
…
assert property(@(posedge d) e |-> ##[1:2] f );
…
endprogram
// A SystemVerilog module can also be
// used in a similar way

Tying SVA to the SC module using a wrapper module:

module sva_wrapper;
bind cpu // Bind to all occurrences of cpu
cpu_props cpu_sva_bind // Bind cpu_props to cpu
// and call this instantiation cpu_sva_bind
(.d(clock),.e(flag),.f(data)); // Connect the
// SV ports to SystemC ports and to the
// internal signals
endmodule

This wrapper module can then be either instantiated or loaded together with the top-level design unit in the simulator to enable actual binding in the simulator. The SystemVerilog bind construct may also be used to extend the critical capabilities offered by including advanced verification features to SystemVerilog.

To facilitate the use of these features in SystemVerilog modules, a similar SystemVerilog module may be created as described earlier in this section.

V. OBSCURE PORT CONNECTIONS

As is evident from the difference in the way SystemC, SystemVerilog, and VHDL are modeled, there will be some types in these languages which do not have any equivalent type in another language. We call these obscure types, since the other language will not be able to see through them at the mixed-language boundary. For the purpose of the second language, these types are treated as a black box. Type-checking is stopped for obscure types at the language boundary and the use model of these types is restricted to propagating connections through the design hierarchy.

Consider a case where a SV design unit wishes to pass an incompatible class object down the design-hierarchy to leaf-level SV instances. If there are any intermediate SystemC models through which the object must pass, they may have no need to interact with that object, but they will have a responsibility to pass it through the hierarchy to their children with its full semantic meaning and integrity intact. Obscure type connections can be used to facilitate such propagation of incompatible objects in the design-hierarchy.

As an example of the use-model of obscure connections, consider the SystemC-SystemVerilog hierarchy in Figure 2. Figure 2: Using Obscure Port Connections at the SC-SV Boundary

Signal S1 of an unsupported SystemC type is passed to the SystemC instance through an obscure port connection. SC_MOD1 further passes this signal through an obscure port connection to the SystemVerilog module SV_MOD2 and to another SystemC module instance, SC_MOD_2. SV_MOD2 uses this signal in a process and returns another signal, S6, of an unsupported SystemC type back to the testbench. SC_MOD2 further passes S1 to the instantiated SystemVerilog module SV_MOD3. Process PR7 in SC_MOD3 uses this signal and drives signal S3 of some incompatible SystemVerilog type to the testbench through the SystemC hierarchy using obscure port connections.

There is an intrinsic support for obscure types in SystemC in the form of void handles. As such, design hierarchies containing sandwiched SystemC modules can be supported without significant changes in the language. However, for a more general solution, if language A wishes to pass an incompatible type through a design hierarchy consisting of language B, language B must have support for obscure types and define the connection rules. As such, obscure types will need to be formally defined as an extension to each language.

VI. CONCLUSION

The productivity of complex hardware system design directly depends on reusable components. The reusability of mixed-language IP is crucial in coping with the challenges in ASIC and FPGA domains. The advent of SystemVerilog, with its rich set of design constructs, forces existing mixed-language design methodologies to be revamped.

The methodology presented in this paper defines a new approach that allows seamless communication between mixed-HDLs at various levels of abstraction. Extending the type of reusability HDL packages across the languages and raising the abstraction level during component reuse results in complex mixed-language designs that are far better and more efficient than single HDL designs. The idea can be realized to take advantage of unique SystemC verification and modeling features without rewriting the functionality available with legacy VHDL packages and IP.

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