katang

Multiple inheritance in SystemC, is it possible?

3 posts in this topic

What is illegal in what I am trying to do?
 

#include "systemc.h"

SC_MODULE (BIT_ADDER)
{
  SC_CTOR (BIT_ADDER)
  {
       SC_METHOD (process);
  }
  void process();
};


class testbench: sc_core::sc_module
{
public:
        testbench(sc_core::sc_module_name nm);
        virtual void test(void) = 0;
};

class testbench_adder: public  testbench,   BIT_ADDER
{
public:
    testbench_adder(sc_core::sc_module_name nm);
        void test();
};

void BIT_ADDER::process()
{}

SC_HAS_PROCESS(testbench);
testbench::testbench(sc_core::sc_module_name nm)
: sc_core::sc_module(nm)
{}


SC_HAS_PROCESS(testbench_adder);
testbench_adder::testbench_adder(sc_core::sc_module_name nm)
:  testbench::testbench(nm), BIT_ADDER("UUT")
{
   SC_THREAD(test);
}

void testbench_adder::test()
{
}

 

Share this post


Link to post
Share on other sites

No, multiple inheritance is not supported in this case 

Here is quote from IEEE 1666-2011

Quote

NOTE 2—Since the classes having sc_object as a direct base class (that is, sc_module, sc_port, sc_export, and
sc_prim_channel) have class sc_object as a non-virtual base class, any class derived from these classes can have at
most one direct base class derived from class sc_object. In other words, multiple inheritance from the classes derived
from class sc_object is not permitted.

 

So you have two options:

  1. Use composition instead of inheritance : in SystemC case this means you need to instantiate modules and bind their ports
  2. In some cases you can put some sc_objects in pure C++ classes (not sc_modules). This technique is commonly used for "port bundles". For example:
struct clock_reset_if {
	sc_in_clk clk{"clk"};
	sc_in<bool> rstn{"rstn"};
}

struct some_module: sc_module, clock_reset_if {
// ...         
}

  

Unfortunately this approach does not work with SC_METHOD/SC_THREAD macros.  But I think it should work with sc_spawn.

 

Philipp A Hartmann likes this

Share this post


Link to post
Share on other sites

Roman is right with his statements and suggested solutions. However, you should also reconsider the structure of your test bench. A test bench should primarily interact with the DUT through its public interface. Therefore, composition is the right choice, i.e., instantiate your BIT_ADDER inside your test bench module as a member variable. Then, bind its ports to signals and drive/monitor them from SC_METHODs/SC_THREADs. This setup resembles test benches in VHDL. You may still use single inheritance in this case to overload certain functions. However, you should pay attention that only one sc_module_name object gets constructed during the construction of you class, e.g., by taking it as a const reference (see clause 5.3 in IEEE Std 1666-2011).

You may also instantiate the test bench module (or separate stimuli/monitor modules) and the DUT on the same hierarchical level from within sc_main() and then connect them via channels.

Share this post


Link to post
Share on other sites

Create an account or sign in to comment

You need to be a member in order to leave a comment

Create an account

Sign up for a new account in our community. It's easy!


Register a new account

Sign in

Already have an account? Sign in here.


Sign In Now