Eyck

This is not entirely true, VCD has the same problems only at a different scale. Writing a text file using fwrite usually employs buffering for performance reasons. Stopping a program using abort (called by a failing assert) will not write this buffer to disc. So the content is lost. Depending of the amount a signals being traced and their activiy you might loose the most interesting part of the trace.... This cannot be fixed in fsdb, you need to modify your sc_main to allow proper closing of trace database(s).

The only option is to close your database properly. BTW, this only applies to VCD or transaction recording (e.g. https://github.com/Minres/LWTR4SC). One way to achieve this under Linux would be to use the setjmp/longjmp mechanism: #include <systemc> ... #include <csetjmp> #include <csignal> using namespace sc_core; jmp_buf abrt; void ABRThandler(int sig) { longjmp(abrt, 1); } int sc_main(int argc, char* argv[]) { signal(SIGABRT, ABRThandler); /////////////////////////////////////////////////////////////////////////// // create toplevel, trace, etc /////////////////////////////////////////////////////////////////////////// ... /////////////////////////////////////////////////////////////////////////// // run the simulation /////////////////////////////////////////////////////////////////////////// int ret = -1; if(setjmp(abrt) == 0) { try { sc_start(); } } catch(sc_report& rep) { sc_report_handler::get_handler()(rep, SC_DISPLAY | SC_STOP); } // make sure end_of_simulation gets invoked if(!sc_end_of_simulation_invoked()) { sc_stop(); } ret = sc_report_handler::get_count(SC_ERROR) + sc_report_handler::get_count(SC_WARNING); } else { ret = -1; } /////////////////////////////////////////////////////////////////////////// // close databases, cleanuo /////////////////////////////////////////////////////////////////////////// ... /////////////////////////////////////////////////////////////////////////// // finish execution returning the number of errors/warnings as exit status /////////////////////////////////////////////////////////////////////////// return ret; } It also reports the number of warnings and errors so that it can be used in CI scenarios or regression testing.

One way would be to set a breakpoint on the report_handler and when it hits the error gp up the call stack. One prerequisite for this would be a debug build of your model.

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.

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