Eyck

I cannot really answer your question but, in my experience the INFO level is used to report normal execution or debugging information during normal execution. Therefore the file name and line number can be ommited.
In any case, you are free to register your own handler. One example of this would be https://github.com/Minres/SystemC-Components/blob/main/src/sysc/scc/report.cpp#L277 which formats the output in a tabular fashion, adds the time and SystemC hierarchy of the unit issueing the log message, and uses a more efficient printing based on spdlog and fmt. The registration of the custom handler can be seen at https://github.com/Minres/SystemC-Components/blob/main/src/sysc/scc/report.cpp#L380.

Which solver(s) did you configure and use?

You are trying to use the AMIQ tools (which worked with a former version of FC4SC) with the refactored Accellera.
You could patch the script at line 30/31 & line 34/35 to check if the divisor is not 0.
But I guess you are better off using PYUCIS which is available via PyPI. There is also a graphical viewer called pyucis-viewer ...
 

When posting code it is best to show an example using https://www.edaplayground.com. I copied part of ypur code at https://www.edaplayground.com/x/NSAs
The problem is the missing initialization of m_trigger_flag. Depending of your build settings and many more factors it might be true or false. When being false the method is only executed during the initial evalauation phase....

Connecting a signal to a port can only happen before the simulation starts (before end_of_elaboartion() ). Signal manipulation can only happen during simulation. So the answer is no.

One example is a APB initiator:
https://github.com/Minres/SystemC-Components/blob/develop/src/bus_interfaces/apb/pe/apb_initiator.cpp#L40 for the notification and
https://github.com/Minres/SystemC-Components/blob/develop/src/bus_interfaces/apb/pe/apb_initiator.cpp#L63 for pulling entries

I don't think so. Although you call notify with a reference it internally stores the pointer to to the object. You as modeler are in charge of the lifetime of the object pointed to. So if you have a shared_ptr with local lifetime (which is the use-model of a shared_ptr) the peq has a danglng pointer once the local shared_ptr is destroyed (not the object it pointed to).
This is one reason we wrote our own peq at https://github.com/Minres/SystemC-Components/blob/main/src/sysc/scc/peq.h

@bsipl_h When modeling, you need to be asking yourself some fundamental questions:
1. Why are you modeling?
To determine the feasibility of a new architecture (interconnect)? To understand timing issues? To create a golden standard against which to RTL development? To allow firmware development to start early? To share with an external customer? To use synthesis tools? 2. What is the focus of the model?
A single component An entire system Interoperability with another system Post silicon validation 3. Who is your customer, and what do they need?
Architect Verification team Firmware team Validation team 4. How "configurable" will the model be?
Limited Allow different timing models/mixes Support different teams Support different connectivities 5. Are there simulation performance goals?
The more details you add, the slower the simulation With fewer details, accuracy may be impacted What is reasonable it required? 6. How much development time do you have for the model?
How much validation is needed? How does it impact others' schedules? How long do you expect this model to be used? How much time do you have? Can you acquire parts of the model from the teams or externally? Can you purchase parts of the model? Answers to the above questions will drive your decisions.
 

Actually you try to call an array operator for the port i_i in mux_4_to_1. This does not access the respective bit in the data but the n-th interface of a (potential) multi-port. So you need to do a explcit read to the the sc_bit and then an array access:
// Multiplexer Logic void mux(){ // Convert bit vector to int int select_value = s_i.read().to_uint(); auto in_val = i_i.read(); switch(select_value){ case 0 : y_o.write(in_val[0]); break; case 1 : y_o.write(in_val[1]); break; case 2 : y_o.write(in_val[2]); break; case 3 : y_o.write(in_val[3]); break; default : y_o.write(false); } } There are several other things to your code:
You should use C++11 You should name your ports and signals. Using C++11 this would look like sc_out<sc_bv<4>> i_i{"i_i"}; This eases debugging (and tracing). sc_main should only instantiate the toplevel module/testbench. No structural code and no signals in sc_main. This eases reuse of modules and porting it to other simulators (Synopsys, SiemensEDA, or Cadence). The only other code should be paring command line arguments, setting up tracing/logging, starting simulation and evaluating the results. It also unifies your sc_main across different models. Maros SC_CTOR and SC_MODULE are discuraged and, as far as I know, will be deprecated and removed from future standards. The do not add substantial functionality.

Actually there is no requirement to use TLM2.0 for any communication. You can mix and match with your use model. TLM2.0 is intended to model bus based communication. So for example interrups, gpio, or alike is nothing to model in TLM2.0.
When starting to model AXI4 you might want to have a look at https://github.com/Arteris-IP/tlm2-interfaces which provides a complete AT implementation of the AXI4, ACE, and ACELite protocol incl. protocol engines and targets. This might gitve you a jump start and avoids 'yet another' implementation. If you miss a feature you are encuraged to file enhancement tickets.
Additionaly at https://github.com/Minres/SystemC-Components/tree/develop/src/bus_interfaces/axi you will find complete drivers and pin-level adapters which allows to connect the AT-TLM to RTL interfaces (the library uses the tlm2-interfaces repo under the hood.
At https://github.com/Minres/SystemC-Components/tree/develop/examples you find also simple examples on how to use  the AXI4 implementation and the pin-level adapters.

This strongly depends on how you struture your testbench. We presented a poster (and had a talk) about using UVM-SystemC to verify a processor (teh pdf can be found here: https://riscv-europe.org/media/proceedings/posters/2023-06-07-Stanislaw-KAUSHANSKI-abstract.pdf). We chose to have TLM2.0 as the VIF which allowed us to hook-up the testbench with a verilated representation of the desing as well as an HDL Simulator or even some FPGA based solution. This way we can re-use the entire tesbench at different abstraction levels.

Please be aware: cxxabi.h is a GCC specific implementation  and will quite likely not work with MSVC or Clang

In both cases there is no difference. The operator=() is overloaded with read() adn write() respectively. So you can use both notions interchangably.
I personally tend to use read() and write() since this expresses my intend.

If you stay in C++ this is the only solution. But by modifying the SystemC kernel you loose standards compatibility.
If you can switch to python there is PySysC (https://github.com/accellera-official/PySysC) which allows to inspect data types at runtime.

You should stick to modern C++. Beyond that SystemC provides sc_vector which handles sc_object based instances better than C arrays do (e.g. when binding ports):
SC_MODULE(regfile) { using reg_t = sc_int<32>; sc_in<sc_uint<5>> rsv1_addr{"rsv1_addr"}; sc_vector<sc_out<reg_t>> rsv1_data{"rsv1_data", 8}; void read_vector(); SC_CTOR(regfile) { SC_THREAD(read_vector); } private: using regfile_t = array<reg_t, 8>; array<regfile_t, 32> v_regfile; // suppose data stored in it }; void regfile::read_vector() { auto& elem1 = v_regfile[rsv1_addr.read()]; for (int i = 0; i < 8; i++) rsv1_data[i] = elem1[i]; while ((true)) { wait(rsv1_addr.value_changed_event()); auto& elem2 = v_regfile[rsv1_addr.read()]; for (int i = 0; i < num_thread; i++) rsv1_data[i] = elem2[i]; } } A few more notes:
If this piece of code is part of a header file: pleas do not use 'using namespace sc_core;' in it. This will lead to problems when later using the code in larger problems. Name your signals and ports. This greatly helps when debugging your design with waveform traces Use C++ std lib datastructures (like std::array or std::vector) as they allow for range checking when built in debug mode. Other than that the code is fine. You cannot avoid the loop based assignment as this implies a type conversion (v_regfile elements is sc_int while rsv1_data is sc_port<...>). And even if there would be some convenience function this would result in a for loop. On the other hand having contigous memory layout (which std::array guarantees) the caching and branch prediction of your processor kicks in and compensates largely for the loop.
BTW, num_thread is not declared, make sure that it sticks to a value smaller than 8. Otherwise you might run into a out-of-bounds access

You might want to have a look at https://github.com/arteris-IP/tlm2-interfaces/tree/develop which is also integrated into https://github.com/Minres/SystemC-Components.

Actually you built your design using C++ 17 as the missing version string indicates. I assume that SystemC has been build with C++ 14 or lower.
In my experience this is a common problem esp. if you use pre-compiled versions of systemc. My suggestion would be to use a package manager like conan. They ensure that the different parts of the design are built consistently. You might want to have a look at https://github.com/Minres/SystemC-Quickstart. This is basically a project template. The only thing to be done before is
pip3 install --user conan and your are ready to go. And you need to make sure that SYSTEMC_HOME is not set.

Declaring run_clk as SC_METHOD and and using a while loop will effectively stop your simulation as time will not progress. next_trigger() will not wait rather trigger the method after the given time.
You should define it as:
#include "systemc.h" SC_MODULE(osc) { sc_in<bool> enable; sc_out<bool> out; SC_HAS_PROCESS(osc); osc(sc_module_name name, uint _delay = 0) : sc_module(name), delay(_delay) { //SC_THREAD(run_clk); SC_METHOD(run_clk); sensitive << enable; } void run_clk() { if (enable.read() || out.read()) { // executes while enable is active or the out is high. If enable is false it will end with out==false out.write(!out.read()); next_trigger(20, SC_NS); } } private: uint delay; }; // End of Module counter  

This is basic C++: you try to use a local variable (h) declared in the for loop as a template parameter. This does not work. You need to modify your ShiftRegister class to take h as a constructor argument.

Seems the compiler cannot infer the read function. SO the example would look like
 
void sY_bit_select() { sc_bv<2*N> write_val; for(auto i=0U; i<2*N; ++i) { write_val[i] = sY_bit[i].read(); } sY.write(write_val); } Actually I personally prefer to use the explicit read() and write() functions instead of the overloads. Those work in many case but -as you encounted- not all.

SCML is not open-source and if you look at section 1 of the LICENSE file the folks already violate the license by providing the source code. So you are left with 2 options...
For simple busses you can go with the TLM2.0 base protocol which works fairly well. SCC supports non-blocking accesses at the registers and memories so you are left to get or write some interconnect component. AFAIK there are no bus implementations available as open-source to be used out of the box.
But you are invited to contribute e.g. to the SCC (you may contact me directly via github).

@acc_sysC, to help clarify a bit more:
sc_signal<T> is a channel, not data. Conceptually, channels provide transport for data for communication. Use the write() method deposits a copy of the data (as a whole) into the sc_signal channel's write buffer (next_value). At the end of the delta cycle, the write buffer is copied into the current_value in it's entirety. The read() method simply returns a copy of the current_value. sc_bv is a data type, not a channel, and supports bit-specific access (reading and writing) via operator[]. Finally, if you use ports (e.g., sc_in<T> or sc_out<T>, which are really just specializations of sc_port<sc_signal_in_if<T>> and sc_port<sc_signal_inout_if<T>> respectively), they are effectively pointers to channels that support the channel's API's. I mention this because newbies to SystemC frequently confuse the ideas of data, channels, and ports.
Finally, before you ask: No, there is unlikely to be any attempt to "fix" SystemC to provide extensions to all of this to make modeling at this (low-level) more comfortable. SystemC attempts to raise the abstraction level and tends to avoid bit/pin twiddling. If you need to code RTL, please use SystemVerilog or VHDL.

No, this is not possible. You are using the array operator for sY_bit which is ok as it is an sc_vector. But on the left hand side you have a signal. A signal has no array operator as it is a single signal.
If you want to assign to a bit position in the bit vector the signal carries you need to read it first, assign and then write since you can only write data of type sc_bv to the signal. So it should look like:
void sY_bit_select() { sc_bv<2*N> write_val; for(auto i=0U; i<2*N; ++i) { write_val[i] = sY_bit[i]; } sY.write(write_val); }  

Your test functions are threads so why not spawn them dynamically and wait for them to finish? This way you neither need the sc_events not the mutex, just sc_spawn and sc_join

Your test functions are threads so why not spawn them dynamically and wait for them to finish? This way you neither need the sc_events not the mutex, just sc_spawn and sc_join