Eyck

To me it looks like if the signal is not being properly constructed. But without additional code it is not possible to give more advise....

In the follwoing linemyselector.out_fifo (ctrl_frame); myselector.out_fifo (ctrl_frame); You are trying to bind ctrl_frame to the sc_fifo_in port. And obviously ctrl_frame is neither a sc_fifo nor implements the sc_fifo_in_if.

Answering your question without having a code example is difficult. You transmit a pointer to BasePort which does not contain the data. Therefore you do not see the data. At your signal sink you need to do a dynamic_cast<> to get a pointer to your Port Your approach to modeling is strange not to say wrong. What Do you want to model between your memory and adder? Actually you describe a signal carrying a pointer to a Port? Usually a signal carries a value (or a set of values aka a struct) and there will only be value changes which manifest as events. Or do you want to model a bus bas

Which compiler version do you use? _randomP is declared as mutable so it should be possible to assign to it even in const member functions. Or maybe you have a define named 'mutable'?

Depends on the system youar eon and the compiler you are using. Here are a few options: https://stackoverflow.com/questions/2099692/easy-way-find-uninitialized-member-variables Unfortunately the reports ar not exhaustive so there is still some work ahead....

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.

One reason I've seen in the past quite often are uninitialized local variables being used in the control flow: int a; ... unsigned b = a; ... if(b>0){ ... } else { ... } Although b seems to be initialize it gets its value uninitialized. Hwo would logging effect this? Depending on the configuration the stack being used has different residual values (from previous funcion executions). Therefore 'a' gets different -unitialized- values which are later used to steer the control flow. Therefore my mantra is always: initialize variables upon declaration. In C++11 this becomes quite easy

If you can avoid global variables at all cost. The will bite you more 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 upone first use which usually gives you some control over the live cycle. Another example can be found here: https://github.com/Minres/SystemC-Components/blob/master/incl/tlm/tlm_mm.h

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

Addresses and data should be modelled as sc_uint<WIDTH> since this forms one signal carrying events. Having a (sc_)vector creates n-signals with n events which adds simulation overhead. It should look like: sc_core::sc_signal<sc_dt::sc_uint<32>> data_i; The latency setting can either be set as a constructor argument or a SystemC CCI parameter.

You need to built the SystemC lib on ubuntu. With the introduction of small string optimization in C++11 gcc decided to move this into a different (inline) namespace (it is called DualABI). The use of of this can be configured at build time of gcc. Basically this is a decision of the distribution and may differ even if the version is the same. You may try to compile your SystemC code with '-D_GLIBCXX_USE_CXX11_ABI=0' or '-D_GLIBCXX_USE_CXX11_ABI=1'. See also https://gcc.gnu.org/wiki/Cxx11AbiCompatibility https://stackoverflow.com/questions/36159238/linking-problems-due-to-symb

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 memo

I don't know what you mean with being 'on readline'. With sc_fifo<int> my_fifo{8} you define a fifo with max. capacity of 8 elements. It is not a pipeline with a fixed depth....

The quantum keeper is used to hold the local time of a time domain in loosly-timed models. E.g. in https://git.minres.com/VP/HIFIVE1-VP/src/branch/master/platform/src/sc_main.cpp#L119 the global quantum is set (the amount of time a time domain is allowed to run ahead). In https://git.minres.com/DBT-RISE/DBT-RISE-RISCV/src/branch/develop/incl/sysc/core_complex.h#L112 the local time is updated (within each instruction) and if the quantum is exceeded, the control is returned to the SystemC kernel (line 114).

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).

Describing particular protocols means extending the base protocol (see also IEEE 1666-2011, section 14.2). There are several ways to do this: ignorable phases (IEEE1666-2011, section 14.2.1, 15.2.5): here you add intermediate timepoints inbetween the base protocol phase timepoint. This allows: 'An ignorable phase may be ignored by its recipient.' define new protocol traits (IEEE1666-2011, section 14.2.2): you define new, non-ignorable phases so the implementation are base-protocol-compliant. This way you can only connect base-protocol-compliant models together The easiest

In the constructor list you would provide a creator function. This is a functor(a function pointer, a std::function object, a Functor classinstance, a lambda function, ...) which accepts a char const* and a size_type and returns a constructed object. In your case it would look like (C++11): class example: public sc_core::sc_module { public: sc_core::sc_vector<sc_core::sc_fifo<unsigned>> fifos; example(sc_core::sc_module_name nm, unsigned outputs) : sc_core::sc_module(nm) , fifos("fifos", outputs, [](char const* name, unsigned i)->sc_core::sc_fifo<unsigned&g

create a signal in the B module and bind it to the sc_export. The you create a SC_METHOD being sensitive to the sc_port. In the method you just read the port value and write it to the signal.

Actually your code is a bit buggy and has some misconceptions. For your convenience I code up your example at https://www.edaplayground.com/x/CfVM Maybe you should read some books (e.g. @David Blacks 'SystemC from the ground up') or checkout some tutorials using a search engine of your choice.

Your do_sum() is sensistive to A_val_in and B_val_in which means wati() finishes as soon as A_val_in or B_val_in gets data. Then you read the data using blocking read. This means the function waits until data in the fifo is available anyways. Your loop could be simplified as void sum::do_sum() { while(true) { unsigned int Sint = A_val_in.read() + B_val_in.read(); S_val_out.write(Sint); sum_finished.notify(SC_ZERO_TIME); } } and you don't need a sensitivity list at all. This can be done also in a non-blocking way: void sum::do_sum() { unsigned int A_v

No, a bool does not provide events. More over of A is true for a longer time how often should the thread be activated? I guess what you need is a clock.

You also need to change the order of sc_start and trace file creation: sc_trace_file *tf=sc_create_vcd_trace_file("trace"); tf->set_time_unit(1,SC_NS); sc_trace(tf,A,"A"); sc_trace(tf,B,"B"); sc_trace(tf,O,"O"); sc_start(SC_ZERO_TIME); Afaik the kernel will not add traces once the simulation passed end of elaboration (which happens with the very first call of sc_start())

If you use #include with angle brackets the current directory is not part of the include search path. So either you use #include "andh2.h" or add the current directory to the list of include directories of the compiler invocation

A SC_METHOD being sensitive to a positive edge of a clock is not a latch rather a register. It is the same than in (System)Verilog or VHDL. Moreover a sc_signal is not a queue at all. Writes in the same delta cylce superseed earlier writes in the same delta cycle. A signal in SystemC is similar to a wire or reg in Verilog or a signal in VHDL. Maybe you should revisit your understanding of RTL description and its logics. There are many ways how to implement things. You may write a lot of different modules what brings a lot of overhead. Usually you implement a pipeline as a set of proc