Amit Bhandu

Several topics here...
 
EFFICIENCY/PERFORMANCE
I hear so often the comment that SC_THREAD is less efficient than SC_METHOD, but the claim is incorrect. It is true that in the Accellera implementation there is a small difference favoring SC_METHOD. I am aware of SystemC implementations where exactly the opposite is true. In general, there are much better things to worry about:
Coding efficiency (how fast can you get a correctly working model written)? Does your code work? Is this the most natural way to write the code? Is your code easy to understand? Are you writing at the correct level of abstraction (RTL is typically inappropriate)? If you are concerned about execution performance, you should be more concerned about the amount of context switching. In other words, how frequently are your SC_METHOD's called and how frequently do your SC_THREAD's call wait(). If you really want to focus on this, remove those clocks. Clocks have two context switches per clock period (rising and falling). You can synchronize to clock timing by treating time as modulus a clock_period variable.
 
The intent of SystemC is to write models and verify (you do hopefully write unit tests) quickly. You should be able to write loosely timed models of your SoC in hours or days - not weeks or months. Approximately timed models may take a bit more time (perhaps a few days to a couple of weeks).
 
SYNCHRONIZATION
As regards synchronization, you need to completely understand the event-driven simulator mechanisms, and use proper handshaking of events or channels to accomplish your tasks. Mutex or semaphore may be appropriate, but not always. Sometimes you need to write your own custom channels. FIFO's are an excellent synchronization method, and make many modeling tasks trivial.

Hi Amit,
If you use your favorite search engine with terms "systemc" and "parallelization", I think you get a nice overview of available work in this area. Next to that, you might also give it a try with IEEE Xplore.
Kind regards,
Bas
 

We await your rewrite of the SystemC kernel. Please make sure it can pass all of the regression tests.

All, if you rewrite the core. SystemC is simply a C++ library. 

I routinely use C++17 with SystemC.
I will suggest we don’t use C++20 for a few more years because:
1. Compilers are still too immature
2. Some of the changes are quite radical and will take time for user education (e.g., coroutines, modules, and ranges)
3. Some changes would possibly require to much refactoring (e.g., modules)

Hi Cam,
  the idea of TLM2 was to create a standard API for transaction level modelling, that runs at high speed, and models memory-mapped buses.
 
So the TLM Working group decided to create standard functions for both blocking and non-blocking transport; and a standard payload object.
 
So the first advantage of using TLM2 over plain SystemC is simply that it is a standard API and payload.
 
To model pipelined transactions, the TLMWG decided to use function calls from target to initiator and initiator to target. To allow function calls to be made in both directions needs a port on the calling module and an export on the target (forward), and a port on the target model connected to an export on the initiator. You could of course do this without sockets but you'd have to make two connections - by using a socket, a single bind call connects both export and port. Also you'd have to explicitly declare the initiator port and target export with tlm_transport_fw_if, and the target port and initiator socket with tlm_transport_bw_if - initiator socket is based on tlm_transport_fw_if and the target socket on tlm_transport_bw_if so you get that "for free".
 
Finally, the sockets also have extra template arguments compared to SystemC ports - the Bus Width parameter. This ensures that the user cannot accidentally connect busses of different widths together.
 
kind regards
Alan
 
P.S. There is another answer I could give:
TLM2 *is* SystemC there is no difference. An initiator is a channel that implements the tlm_bw_transport_if. The target is a channel that implements the tlm_fw_transport_if. So the only difference from the "traditional" use of SystemC is the idea of a socket to provide simultaneous binding of the both port and export. If you want to, you could create your own exports and ports, and connect them yourself.