Can I use TLM-2.0 without SystemC library?

[taog]

Hi all, in my opinion, TLM-2.0 defines the communication protocol between modules. Can I just use TLM-2.0 generic payload/b_transport without SystemC, just in a pure C++ enviroment??? When I compiled my C++ program which have included TLM2 headers, it give me some errors, like below:

undefined reference to `sc_core::sc_port_base::add_static_event(sc_core::sc_method_process*, sc_core::sc_event const&) const'
Must I link SystemC library to use TLM-2.0? i'm using SystemC-2.3.0

[maehne]

The implementation of the TLM proof-of-concept library depends on SystemC. Therefore, you will need to link your application, which makes use of TLM, to the SystemC library. You can check it yourself by looking into the corresponding TLM headers: They include headers that are part of the SystemC implementation. Furthermore, the TLM implementation is not anymore header-only.  The compiled .cpp implementation files are directly linked into the SystemC library file.

[taog]

12 hours ago, maehne said:

The implementation of the TLM proof-of-concept library depends on SystemC. Therefore, you will need to link your application, which makes use of TLM, to the SystemC library. You can check it yourself by looking into the corresponding TLM headers: They include headers that are part of the SystemC implementation. Furthermore, the TLM implementation is not anymore header-only.  The compiled .cpp implementation files are directly linked into the SystemC library file.

Ok, I see. Another question, can I use TLM-2.0 infrastructure like initiator socket/target socket/generic payload/socket bind/register b_transport function without trigger systemc kernel by using sc_start in my pure C++ simulation enviroment?

[Roman Popov]

2 hours ago, taog said:

Ok, I see. Another question, can I use TLM-2.0 infrastructure like initiator socket/target socket/generic payload/socket bind/register b_transport function without trigger systemc kernel by using sc_start in my pure C++ simulation enviroment?

At least you need to finish elaboration, using  sc_start(SC_ZERO_TIME); 

But usually TLM-2.0 models cannot be used without SystemC scheduler, since TLM models are allowed to use SystemC primitives like processes and events.

[taog]

On 2/19/2019 at 1:12 PM, Roman Popov said:

At least you need to finish elaboration, using  sc_start(SC_ZERO_TIME); 

But usually TLM-2.0 models cannot be used without SystemC scheduler, since TLM models are allowed to use SystemC primitives like processes and events.

It seems I can not use tlm2 socket like simple_initiator_socket/simple_target_socket in a pure C++ class which do not inherent from sc_module. Is TLM2 socket tight coupling with sc_module? Can I decouple this relationship?

[Philipp A Hartmann]

7 hours ago, taog said:

It seems I can not use tlm2 socket like simple_initiator_socket/simple_target_socket in a pure C++ class which do not inherent from sc_module. Is TLM2 socket tight coupling with sc_module? Can I decouple this relationship?

Yes, TLM sockets are dependent on SystemC and can only be used inside of a SystemC module.  This is because they are implemented via SystemC ports/exports, which can itself only be instantiated in SystemC modules as per the SystemC standard.

If you want to bridge into a pure C++ model, you can pass the corresponding interface pointers into your C++ model via your own code (via get_interface() after elaboration).  This way, you only depend on sc_interface from SystemC (which is a base class of all SystemC/TLM interface classes) inside your C++ model.

I'm not sure, what you are trying to achieve, though.  Why can't you use SystemC (which is just C++ at the end anyway)?

Greetings from Duisburg,
  Philipp

[taog]

13 hours ago, Philipp A Hartmann said:

Yes, TLM sockets are dependent on SystemC and can only be used inside of a SystemC module.  This is because they are implemented via SystemC ports/exports, which can itself only be instantiated in SystemC modules as per the SystemC standard.

If you want to bridge into a pure C++ model, you can pass the corresponding interface pointers into your C++ model via your own code (via get_interface() after elaboration).  This way, you only depend on sc_interface from SystemC (which is a base class of all SystemC/TLM interface classes) inside your C++ model.

I'm not sure, what you are trying to achieve, though.  Why can't you use SystemC (which is just C++ at the end anyway)?

Greetings from Duisburg,
  Philipp

Because in my project, we need to use our models in a non-SystemC simulator(C++ based). We do not want to use SystemC scheduler. We only want to use TLM-2.0 to unify function calls between our modules. Another thing is that we do not want to link SystemC library because SystemC seems have some global objects which may not easy to support checkpointing.

[Roman Popov]

1 hour ago, taog said:

Because in my project, we need to use our models in a non-SystemC simulator(C++ based). We do not want to use SystemC scheduler. We only want to use TLM-2.0 to unify function calls between our modules. Another thing is that we do not want to link SystemC library because SystemC seems have some global objects which may not easy to support checkpointing.

In our environment we have one simulator that uses SystemC hierarchy and elaboration, but does not use SystemC scheduler. There is no problem with check-pointing : when we need to restore from checkpoint we just re-run SystemC elaboration and then apply checkpoint state.

But using TLM-2.0 without SystemC elaboration is not possible, because internally it has core SystemC objects like ports and exports. So probably you don't need SystemC at all.

[taog]

21 hours ago, Roman Popov said:

In our environment we have one simulator that uses SystemC hierarchy and elaboration, but does not use SystemC scheduler. There is no problem with check-pointing : when we need to restore from checkpoint we just re-run SystemC elaboration and then apply checkpoint state.

But using TLM-2.0 without SystemC elaboration is not possible, because internally it has core SystemC objects like ports and exports. So probably you don't need SystemC at all.

I'm really agree with you. I think it's because of we do not familiar with SystemC implement, and not sure if it would bring us some side-effects or restrictions when we apply SystemC in all our models. What we need is that we can reuse our models under different simulators with as less effort as possible.