Roman Popov

In general avoid using multiple inheritance for aggregation. It is possible, but has many drawbacks and no major benefits. Now I regret that I've written original post, but at that time I had no enough experience myself. Now, if we read any object oriented design book, we will learn that inheritance usually means "is-a" relation ship, and "has-a" relation ship is expressed by composition. Translating into HW modeling : what we want to express is that "some_module has port bundles", and not "some_module is port bundles". We can still use single inheritance in limited cases, for example if all modules in design have clock and reset, we can have a common base class like class clocked_module : public sc_module Back to your example. I recommend to convert your port bundles into modules: struct if_inputs : sc_module { sc_inout<sc_uint<4>> SC_NAMED(R_OP_MODE); sc_inout<sc_uint<8>> SC_NAMED(R_PRESET_MANUAL); if_inputs(sc_module_name){} }; struct if_outputs : sc_module { sc_inout<sc_uint<2>> SC_NAMED(T_BIT); sc_inout<sc_uint<4>> SC_NAMED(T_OP_MODE); sc_inout<sc_uint<8>> SC_NAMED(T_PRESET_MANUAL); if_outputs(sc_module_name){} }; And now you can aggregate any number of them inside monitor. Even have a vector of port bundles: class monitor : public sc_module { public: if_inputs SC_NAMED(sim_inputs); if_outputs SC_NAMED(sim_outputs); if_inputs SC_NAMED(stub_inputs); if_outputs SC_NAMED(stub_outputs); sc_vector<if_inputs> SC_NAMED(inputs_vector, 3); monitor(sc_module_name name_); private : // implementation details };

SystemC standard does not guarantee any order of process evaluation within a single delta cycle. So in first example both 2,4 and 4,2 will be correct.

They are in namespace sc_core. If you don't want to use namespaces you can change #include <systemc> to #include<systemc.h> and it will pull everything into global namespace.

I mean if you don't need to connect the port, then don't create the port. This is the idea.

Other option is to pass some flag to constructor struct my_module : sc_module { std::unique_ptr< bus_port > bus_slave; my_module(sc_module_name, bool has_slave_port) { if (has_slave_port) { bus_slave = std::make_unique<bus_port>("bus_slave"); } } For SystemC 2.4 there is a sc_optional<T> class proposal that will allow to create ports "on demand" at any time during elaboration.

Clang 5 works fine for me on Linux. This may be a combination of Clang + Cygwin. According to benchmarks https://www.phoronix.com/scan.php?page=article&item=gcc-clang-2019&num=4 compilation time difference for most projects is within 10%.

Clang 8 is quite new compiler and SystemC 2.3.3 was not tested against it. Do you see this issue only in Cygwin? Or in general with Clang 8, including Clang 8 on MacOS / Linux ?

I don't immediately see a problem in code. Just a guess: Have you configured all compiler flags? In case you use CMake it should be automatic. If you create project manually you can check here https://stackoverflow.com/questions/41990606/installing-systemc-for-vs2013/41991699

Clang AST is the best opensource option, but some extra work will be required to support SystemC. With Clang you can quite easily reproduce Pinapa approach. Don't recommend going PinaVM way with using LLVM IR - It is too low level for most SystemC analysis tasks.

Shared libraries and dynamic linker are explained many times on a web, let me google it for you.

Because dynamic linker does not know where to find library. You have two options: use -Wl,rpath,<path/to/lib> command line option at compile time, or set LD_LIBRARY_PATH environment variable. Google for more details.

e.notify(); // immediate notification is executed "immediately" - Thread2 added to set of runnable processes e.notify(3,SC_NS); // e added to kernel event queue, it will be triggered in 3 ns e.notify(3,SC_NS); // e added to kernel event queue to be triggered in 3 ns e.notify(); // previous notification canceled, and instead event is notified immediately, Thread2 added to set of runnable processes

Setting library path != Linking library. Also add -l systemc to g++ options.

Question is too generic. If you have cycle-accurate pin-level model you need to interface with, you will have to write a transactor class that converts functional TLM interface to pin-level protocol. Usually it is implemented as SC_THREAD process sensitive to clock edge.

You forgot to link SystemC library.