Eyck

The simple answer is: use a commercial tool, this is where they shine.
If you want or need to stick to freely available tools there is to my knowledge nothing better as gdb, tracing, and printf debugging.
For the latter you would need to instrument your code to print out what happens atr wihich time. I saw huge models using the approach generating  GBs of log output on . demand. Pretty helpfull is a structured output with a single line per log message having the time and the hierarchy of the originator. One option would be to use the report system in the SCC which build upon and extends the SystemC report system, pls have a look at https://minres.github.io/SystemC-Components/main/report_8h_source.html
Tracing would use VCD output and transaction recording base don the SCV.
I personally tend to use gdb with all of its features like:
dprintf debugging to temporarily create a text trace conditionlal breakpoints based on the this pointer to enable breakpooints for a specific instance (e.g. if there are several instances of the same module) conditionlal breakpoints based on sc_core::sc_time_stamp() (the SystemC library needs to be compiled in debug mode). This allows breakpoints be triggered after a certain simulation time watchpoints to observe a variable an it's value change

You need to connect the output port to a signal and attach a method to the signal driving the multiple output ports. So something like this:
template<> struct Carries<1> : ::sc_core::sc_module { sc_vector<sc_in<bool>> a, b; sc_in<bool> rIn; sc_out<bool> p, g, rOut; sc_vector<sc_out<bool>> carries; CarryPropGen pg {"PG"}; SC_CTOR(Carries) : a {"vectA", 1}, b {"vectB", 1}, rIn {"rIn"}, p {"p"}, g {"g"}, rOut {"rOut"}, carries {"vectCarries", 1} { pg.a(a[0]); pg.b(b[0]); pg.r(rIn); pg.p(p); pg.g(g); pg.rOut(rOutS); // What I would like to do. SC_METHOD(propagate); sensitive<<rOutS.value_changed(); } sc_core::sc_signal<bool> rOutS; void propagate(){ rOut.write(rOutS.read()); carries[0].write(rOutS.read(); } }; BR

Just to add to Davids answer: TLM or Transaction Level Model is as the name suggest a way to model bus transactions. In using this the abstraction level is raised and a bus access is described as either a blocking transaction which is atomic in the view of the initiator or as non-blocking transaction having a request/response phase in the base protocol. The first is usually used together with direct memory accesses (DMI) in models which are supposed to run fast (e.g. VPs to develop SW). The latter are used to describe timing properties more accurately. The base protocol being part of the SystemC reference implemention can be used for this of the bus transactions are fairly simple (e.g. APB). More advanced protocols liek AXI, OBI, or CHI need a more elaborate protocol implementation. For AXI you might find one at https://github.com/arteris-IP/tlm2-interfaces/ having a documentation at  https://github.com/Arteris-IP/tlm2-interfaces/blob/master/doc/axitlm/axi_tlm2_spec.pdf. Examples of use can be found at https://github.com/Minres/SystemC-Components/tree/develop/examples

There is no level of accuracy as this would imply some fuzzyness. The simulation kernel follows the discrete event simulation protocol and as such it is deterministic and has exact timing. So if your event is triggered with a delay of 60us the notfier is triggered 60us later. The only thing which the standard does not guarantee is the order of invocation within delta cycles as this is an implementation detail (e.g. some simulators offer to randomize this).
I can imagine several root causes:
there is some uninitalized value which leads to accidental increment of the time value handed into the call of register your event gets notified 1ps after the notification in register(). This effectivly cancels the first notification Commercial tool of the well-known EDA vendors offer means to check pending notifications. The reference implementation does not have this, here you would need to hooj into the simulation kernel.
 

There is no level of accuracy as this would imply some fuzzyness. The simulation kernel follows the discrete event simulation protocol and as such it is deterministic and has exact timing. So if your event is triggered with a delay of 60us the notfier is triggered 60us later. The only thing which the standard does not guarantee is the order of invocation within delta cycles as this is an implementation detail (e.g. some simulators offer to randomize this).
I can imagine several root causes:
there is some uninitalized value which leads to accidental increment of the time value handed into the call of register your event gets notified 1ps after the notification in register(). This effectivly cancels the first notification Commercial tool of the well-known EDA vendors offer means to check pending notifications. The reference implementation does not have this, here you would need to hooj into the simulation kernel.
 

Verilator generated a port having a datatype of unsigned int. You try to bind it to a signal having a data type of sc_uint<32>. This is not possible. Either you declare y in sc_main as sc_signal<unsigned> or you instruct verilator to use sc_uint for its ports by passing '--pins-sc-uint' as command line argument.

I guess there aren't general recommendations. It depends on what your scenario is and what you want to analyze. If it is SW bringup without a lot of hardware->software interactions a large quantum is ok. I had casse where the booting of Android with a quantum of 10-100ms (running the system with 500MHz) was ok. On the other hand if you have dense HW/SW interactions then a quantum of 16 cycles may be the limit as other wise the syncronization is gone...

No. In your memcpy you would not change the target address. So &(data[marker]) would become data. Basically the payload data contains N blocks of size streaming_width all to be written to the same address given by the payload address. No. The bus has to transfer data_length/(BUSWIDTH/8) beats of data. streaming_width only tells the target how to interpret the data. Since the answer to question 2 is no there is nothing to be considered in relation to streaming_width, only in relation to data_length. In short streaming_with is an attribute telling the target how to interpret the transferred chunk of bytes. In that it can be seen as an abstraction of AHBs  HBURST setting WRAP*

You are readfing the port in the construcotr. At this time the port has no connection to a signal and you get the error message. You migth move this part to either end_of_elaboration() or start_of_simulation() or drop it at all.

Why not use constructor prameters? Another option would be cci_params. Via the broker they can be given a value before they are created. So you can use them in contructor bodies....

Why not use constructor prameters? Another option would be cci_params. Via the broker they can be given a value before they are created. So you can use them in contructor bodies....

Why not use constructor prameters? Another option would be cci_params. Via the broker they can be given a value before they are created. So you can use them in contructor bodies....

The simplest solution would be to pass a pointer (or reference) to OS_Task or the TCB with task_create() and task_end(). A forward declaration alogn with the OS_API class should be sufficient.
I don't know your requirements but it seems to me that your use of sc_module is sub-optimal for the purpose of modeling OS tasks. The reason is simple: you cannot create or delete sc_module after the elaboration phase. And OS tasks tend to be dynamic... So sc_object and sc_spawn might be a better solution.
I assume that task_create() and task_end() always surround the behavior of a task. So why not move them into the OS_Task itself? If you pass then the TCB as pointer or by reference you could encapsulate the entire stuff of task handling in the OS_task class...

I took your eample and pasted it at https://www.edaplayground.com/x/EtqQ
From there is works without any hassle.
You seem to have anything different in your code base than posted here.

tlm_fifo provides a blocking read called get() as well as an event to use: ok_to_get(). To block the writer you can use ok_to_put() which is triggered when the fifo is read.

If you can avoid global variables at all cost. They will bite you more than you think. If you need to have static global variables (e.g. for loggers or memory managers) use the Meyers-SIngleton. Those will be initialized upon first use which usually gives you some control over the life cycle. Another example can be found here: https://github.com/Minres/SystemC-Components/blob/master/incl/tlm/tlm_mm.h

I had a look onto your code and it has several flaws:
your condion variable not protected against spurious and lost wakeups you use one global condition variable for all threads. This is bad design... your simulation runs out of events. Since the SC kernel does not see any events during the start of your thread(s), it simply shuts down the simulation. So before your thread is alive there is no simulation at all diamond problem with multiple inheritance: ThreadSafeEvent inherits of sc_prim_channel and ThreadSafeEventIf where both inherit of sc_interface. So at least ThreadSafeEventIf needs to ingerit virtual. Instead of dealing with pthreads you should use std::thread and friends. This eases your life quite a lot an makes things easier Based on your example I created a working example at https://www.edaplayground.com/x/Nn9e using C++11. Make sure that in the field 'Compile Options' the option '-pthread' is given as well as c++11 or c++14 is selected
 

SystemC is a single-thread simulator and moreover not thread-safe  due to various reasons. The problem you are facing is that you modify datastructures in the SystemC kernel (by calling notify() ) asyncronously since you are running it in another (OS-)thread. This might work in some case but in most cases it will not. To cut a long story short you cannot use sc_event to syncronize os-threads.
But there are means to handle this case namely async_request_update(). To see an example you might check out https://stackoverflow.com/questions/49814756/async-request-update-example-in-systemc esp. the implementation of class ThreadSafeEvent.
One remark: I strongly suggest to use C++11 and there std::thread since it makes your code more readable and abstracts from the underlying API. E.g. PThread is not a native Windows thread implementation rather belongs to some POSIX layer which might introduce additional issues.

No, you cannot run the SystemC simulator kernel as a Linux kernel module for sevberal reasons:
SystemC requires quite some libraries (libc, libqt, ...) that are not available in kernel space You would taint the kernel and open up a security hole large as a gate. You would alos risk the system integrity. SystemC is simply not meant for such things. A proper design would make a distinction between (as little as possibel) code to run in kernel space providing interfaces (devices or shared memory) to interact with and a userspace application which could be the SystemC simulation e.g. running as a daemon. Even linux kernel hackers move everything into this direction...
Yes, the simulation is a simple userspace process being constraint by the OS permissions. So it can use all resources a process is allowed. It can open socket connections and ports and whatever it needs. In the past I wrote some interface which allowed the SystemC simulation running on a Linux system to talk to another simulator running on a Windows host using network sockets (it also worked with UNIX domain sockets). And actually we are implementing a SystemC simulation talking to an FPGA on an accelerator card via device files.
Unfortunately I'm not aware of freely available examples to do so. But if you have some C/C++ code to deal with the netlink sockets you can just embed this code into the simulator e.g. as part of a sc_module and tie it to the simulation phases (open the socket during start_of_simulation(), closing them during end_of_simulation()).

Yes, it is possible. Since SystemC is basically a C++ class library you can you whatever C/C++ allows for.

Well, sc_fifo is not TLM.
For your example the basic question is: what is the protocol on fifo_out? Should it be clock-based? Valid-Ready signaling? So your queastion and example is too generic and broad.
If you are looking for an example to translate from TLM2.0 to pin level of an Amba AHB protocol you may have a look here: https://git.minres.com/SystemC/SystemC-Components/src/branch/master/incl/tlm/ahb/bfm and  https://git.minres.com/SystemC/SystemC-Components/src/branch/master/src/tlm_ahb_bfm_initiator.cpp as well as https://git.minres.com/SystemC/SystemC-Components/src/branch/master/src/tlm_ahb_bfm_target.cpp. They implement TLM2.0 to pin and pin to TLM2.0

Actually the usual bus protocols allow to send larger number of requests and the interconnect is allowed to answer them 'out of order' (e.g. AMBA AXI or CHI). But you are free to define you onw protocol and its own rules. The LRM states exactly how to do this. One example can be found at  https://github.com/Arteris-IP/tlm2-interfaces which defines the extensions and phases for the AXI/ACE and the CHI protocol.

Actually the usual bus protocols allow to send larger number of requests and the interconnect is allowed to answer them 'out of order' (e.g. AMBA AXI or CHI). But you are free to define you onw protocol and its own rules. The LRM states exactly how to do this. One example can be found at  https://github.com/Arteris-IP/tlm2-interfaces which defines the extensions and phases for the AXI/ACE and the CHI protocol.

This part is wrong:
for ( int i=0; i<N ; i++){ for ( int j=0; j<NB_elements_trans ; j++){ i_adder = new adder("i_adder"); i_adder->in[j](sig_data[i][j]); } i_adder->out(sig_add); } You create N x NB_elements_trans i_adder elements and on each of them you only connect 1 of 4 in ports. I guess you mean:
for ( int i=0; i<N ; i++){ i_adder = new adder("i_adder"); for ( int j=0; j<NB_elements_trans ; j++){ i_adder->in[j](sig_data[i][j]); } i_adder->out(sig_add); } A few remarks:
you create a memory leak by assigning objects created with new to the same variable you should not use raw pointer. Use C++11 unique_ptr instead Name you SystemC objects, this helps debugging. C++11 makes it easy witn in-class constructors, e.g.: sc_signal<double> sig_add{"sig_add"}; don't use plain C-style arrays, uses either std::array or std::vector. These provide range checking capabilities and help finding out-of-bounds problems don't use C  or C++arrays for SystemC objects. Use sc_core::sc_vector instead use proper formatting, this eases reading (an IDe or clang-format is your friend). Keep in mind: code is a hundret times more often read than written!

Actually you cannot use sc_core::sc_fifo for this as it takes ownership of the data which doesn't play well with the concepts of the generic payload. But there are event queues in tlm_utils for this (tlm_utils::peq_with_get and tlm_utils::peq_with_cb_and_phase).