Eyck

Neither of the 3 is part of SystemC. I guess the come from some 3rd party library... Without any context it is close to impossible to give any further help.

Can you provide a complete example for the issue to reproduce it? Either as tar-archive or on https://www.edaplayground.com ?

There is no way to enforce an ordering on thread or method invokation. One way to achieve this is to make send_m sensitive on the queue (using sc_fifo or tlm_utils::peq*) and let the other processes write into this queue.

They have been further developed and we moved them to github: https://github.com/Minres/TGC-VP https://github.com/Minres/HIFIVE1-VP

Usually this does not work. There are quite a few dependenies to OS and compiler libraries which prevent this. If you build systemc as a shared library there is some chance to get it work.

You still have the same issue. If you would name your port this would help in debugging since the error message points to the respective port by name. A guess is that you bind the port readsig in the module control to a signal and d_memreadsig of module thunder in the SOC. It is a guess as all the other files are missing on edaplayground You need to keep in mind: a sc_port and hence a sc_in/sc_ouz/sc_inout only forward the functions of a signal. Therefore it can only be bound to a single signal, usually at top level. Another thought: it might be beneficial to write testbenches and unit tests for your leaf modules and then combine them up then you stumble upon sucher errors early on and based on your last increment. This makes it easier and helps you to understand the constraints imposed by C++ and SystemC.

Which solver(s) did you configure and use?

You do not specify what you want to achieve therefore it is hard to give any advise. Ports and exports in SystemC forward and expose a function interface, they act as proxy. To have something bidirectional you need to compose a port and an export. TLM sockets implement something like this so this might be what you are looking for...

In your case you have to use the plcaement-new as described here: https://en.cppreference.com/w/cpp/language/new I would suggets to use C++14 constructs: std::array<std::unique_ptr<sc_fifo<SomeClass>>, 4> s1; for(size_t i = 0U; i < n; i++) { s1[i] = std::make_unique<sc_fifo<SomeClass>>("FIFO_"+std::to_string(i)).c_str(), i*1024); } This one manages the life time of your created objects...

Dumping a bunch of code with some screenshots is not really helpfull, you even did not ask a question. Looking at you unformatted and hard to read pasted code, pe[i][j]->pSum_out port is not bound if j is larger than 0. If you would name your ports properly (which is fairly straight forward using C++11), the error message would exactly tell you this.

Both modules m1 and m2 in sc_main have signal ports. These ports have to be connected to signals in sc_main.

Well, the one you reference i swork in progress. Maybe you best bet is to use https://github.com/Minres/fc4sc which is a fork of the AMIQ repo and contains the fixes to make it (Py)UCIS compliant. For the Accelera FC4SC we use our own writer as the one being part of FC4SC does the reporting of groups in a way that does not fir our needs. But this writer is part of our design project.

You need to take care yourself as the factory just calls new and returns a raw pointer. You should use a std::unique_ptr to hold the raw pointer: #include <memory> std::unique_ptr<A> a{A::type_id::create("item", this)}; or if you have to keep declaration and initialization separate: #include <memory> std::unique_ptr<A> a; a.reset(A::type_id::create("item", this)); This way C++ takes care of destruction properly

As far as I can tell PyUCIS cannot cope with the XML prolog. You might be able to run it by deleting the first line in the XML. To my experience the original FC4SC implementation by AMIQ did not conform fully to the UCIS schema. I don't know how the Accellera version behaves...

You do not show where you bind the input ports x and b to signals. You problem is not with the hierarchical binding from ComputeUnit::b to GroupDot::b

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

Recent reworks changed the implementation. You need to use #include <xml_printer.hpp> ... std::ofstream ofs(report_file_name); if(ofs) ucis_printer::coverage_save(ofs);

You might have a look at the trace file implementations coming with the SCC. Although not having the last N cycles amongst others they allow to delay the start of tracing. Other than that they also provide a implementation to trace into FST so that gtkwave can better handle it. At the last Fika there were some presentations around the topic of tracing: https://systemc.org/events/scef202309/ The second one contains also a few numbers...

If I got you rigth you want to trigger the method exactly once after 2ns, right? In that case I would write the TestPlatform differently: class TestPlatform : public sc_core::sc_module { public: SC_HAS_PROCESS(TestPlatform); TestPlatform(const sc_core::sc_module_name& name, const int freq) : sc_core::sc_module(name), m_trigger_flag(true) { SC_METHOD(Push); dont_initialize(); sensitive<<trigger_evt; trigger_evt.notify(sc_core::sc_time(2, sc_core::SC_NS)); }; void Push(){ std::cout << sc_core::sc_time_stamp() << std::endl; } private: sc_core::sc_event trigger_evt; };

That depends on how much you can build on in terms of HDF5. I did a few implementations of some trace files (optimized VCD as well as FST, you can find them here: https://github.com/Minres/SystemC-Components/tree/develop/src/sysc/scc, e.g. fst_trace.hh or vcd_push_trace.hh). My guess would be around a week if you do not have to fiddle with the HDF5 format. But as far as I can judge, HDF5 is not really good at storing trace data efficiently. You have to define a structure on top of HDF5 which takes some time to define efficiently....

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.

This is a fairly complex topic. I try to summarize in a few sentences At first you need to define what your requirements are. Let's assume you have a piece of software which needs to run at a certain speed. So the most important factors to this is the perfomance of the processor in terms of instruction per cycle and the performance of the interconnect and memory subsystem in terms of bandwidth and latency. In the next step you need to gather or develop respective models running in cycle-approximate (CA) or cycle-accurate (CT) mode. They need to provide means to collect the timing information like signal and transaction traces. Then you setup test runs and collect the information. In a postprocessing step you can then calculate the relevant measures and check them against your requirements. Now you can reconfigure your elements until the measures fulfill the requirements. Important here is that you need CA or CT models for the interconnect(s) and the processors. If using TLM2.0 based AMBA interfaces, you might have a look at https://github.com/Arteris-IP/tlm2-interfaces which is also integrated into https://github.com/Minres/SystemC-Components which provides a few more AT protocol implementations on top.

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