Question

I'm migrating from C++ to SystemC, met following basic questions. (I've searched in google, but only got examples in a single .cpp file). Thanks in advance.

I know following "hello.cpp" works:

//hello.cpp
#include "systemc.h"

SC_MODULE (hello_world) {
  SC_CTOR (hello_world) {   
  }
  void say_hello() {  
    cout << "Hello World.\n";
  }
};

int sc_main(int argc, char* argv[]) {
  hello_world hello("HELLO");
  hello.say_hello();
  return(0);
}

Question 1: How can I separate it into hello.h and hello.cpp? Following code is in C++, I don't know how to create the equivalent SystemC code.

//hello.h
class hello_world
{
public:
    hello_world();
    void say_hello();
};

//hello.cpp
hello_world::hello_world()
{
}

hello_world::say_hello()
{
    cout << "Hello World.\n";
}

Question 2: How to create nested class in SystemC? E.g. what is the equivalent SystemC code according to following C++?

class foo
{
public:
    int fooAttr1;

    class bar
    {
    public:
        int barAttr1;
    };
};

Question 3: Where is the best place to specify an attribute/operation's scope? (public/protected/private).

Was it helpful?

Solution

When separating out the implementation from the declarations in SystemC, you can do it the normal way as it is done in C++.

But when you want a constructor with more than one argument(except the default one i.e. SC_CTOR accepts the module name) you will have to define your own constructor.
And if the module has SystemC processes(SC_THREAD, SC_METHOD, SC_CTHREAD) then you will have to use the SC_HAS_PROCESS macro to indicate that your module has process/es.

And regarding nested class it is the same thing as in C++.

I am not sure what you mean by the 3rd question.

OTHER TIPS

regarding your 3rd question: you can do same as you usually do in a C++ program. The best place to specify an attribute/operation's scope is the declaration part of the SC_MODULE, whether you put it in cpp or header file. In a SystemC design, normally only the ports and constructor/destructor should be defined as public to allow other modules to connect with it, unless you have a strong reason and want to break the modularity of a systemc design to access explicitly the member functions of a module.

Licensed under: CC-BY-SA with attribution
Not affiliated with StackOverflow
scroll top