Jump to content

Roman Popov

Members
  • Content Count

    347
  • Joined

  • Last visited

  • Days Won

    45

Everything posted by Roman Popov

  1. I see at least 1 bug in code sample: for (auto val : var.read()) here you create copies of vector elements on a stack of your function. And then pass references to them into SystemC kernel. So those will be dangling references one you return from your sc_trace overload. Change to: for (auto & val : var.read())
  2. Compiler already shown you where is the error and how to fix it. SystemC is a C++ library, you will need to learn C++ and get comfortable with g++ compiler before digging into SystemC.
  3. VCS invokes g++ automatically. But this is correct, sc_main is missing.
  4. This is correct, you cannot trace dynamic data structure. This is not even a SystemC limitation, but limitation of VCD waveform dump in general. VCD does not allow to add/remove signals to waveform dynamically. So usually you have two options : 1) If maximum capacity is known in advance and is small, you can create your own "list" that utilizes statically sized array as a storage: template<typename T> struct my_list_item { bool has_value = false; T value; } template<typename T, size_t MAX_SIZE> class my_list { std::array<my_list_item, MAX_SIZE> storage; // ... } 2) If maximum size is large or unknown, but it is sufficient for you to trace only head and tail of the list, you can have a copy of tail and head that is updated on every push and pop: class my_list { std::list<T> storage; my_list_item head_copy; my_list_item tail_copy; //... custom push pop }
  5. Looks like XY problem to me. If you need pointer to event, use pointer.
  6. Interesting, I'm not an expert in CMake, but even with existing CMakeLists.txt when I build my application SystemC include directory is recognized automatically as system headers: And as a result I don't receive any warnings about issues in SystemC headers.
  7. You forgot ";" here: using namespace std;
  8. Then I have no idea. Set breakpoint on this report and analyze why it gets there. From my perspective your code sample should work without Warnings.
  9. I've reproduced the issue on Centos7. Preliminary it looks like a misuse of mprotect on memory allocated with new. So as a workaround commenting out stack protection section should work. Since I don't have enough linux system programming expertise I will bring it to accellera wg discussion before submitting a fix to systemc repo. Thanks a lot for reporting this and spending your time on investigation!
  10. I was not able to reproduce. What g++ version do you use? Can you provide any example that reproduces the problem? I don't see that path, which line of code?
  11. Also can you run make check after build to see if it is only your example that fails, or some bundled examples also fail.
  12. I have no explanation. Can you please write the steps how you build SystemC library. Will try to install Centos7 on VM and reproduce your steps.
  13. Did you probably forget to add wait() into consumer thread to suspend it after first read?
  14. Here is how it is specified by standard: So it notified after each delta cycle where fifo was read. Can it be that your receiver does nb_read from empty fifo?
  15. Also can you check if failing array in your test is indeed allocated in BSS? (Print values of p pointer before crashing)
  16. Indeed, quote from that thread: So it could be that SystemC co-routine stack was allocated in BSS and setting mprotect on redzone failed. And the difference between CentOS and Ubuntu can be explained by difference in malloc implementation. So indeed can be a bug in SystemC. Can you comment-out assert in stack_protect function in SystemC kernel, rebuild it, rebuild your application and check if it works?
  17. I don't have any CentOS machine now. I've run your example on SLES 11 with gcc 4.8 and it returned no errors. Also I don't understand how your code sample can detect memory corruption in SystemC, can you explain?
  18. Probably SCTIME_CLOCKTIME expands to nothing in your case?
  19. No, they are not equivalent. They notify different events: wait ( time ); // notify active thread == self-notification FIFO_write_event.notify (time); // notify FIFO_write_event
  20. You can report a bug on this forum. Or on github https://github.com/accellera-official/systemc/issues. ../../../../src/sysc/kernel/sc_main.cpp:55: int Check_mprotect(void*, size_t, int): Assertion `ret == 0' failed. I don't see Check_mprotect in sc_main.cpp. Can it be that you have modified SystemC kernel (non-Accellera)? If this is the case you should probably contact support of your SystemC vendor. Why you put extern "C" there? SystemC is C++, and C does not support exceptions. SC_REPORT_FATAL throws exception, and once it reaches your sc_main it is UB (undefined behavior) what happens next. SC_API_PERFORM_CHECK tries to check if SystemC library and user application where compiled with same options and same C++ standard. Looks like exception is thrown when SC_DEFAULT_WRITER_POLICY is configured differently. CentOS 7 supposed to be equivalent to RHEL 7. And RHEL is often used for SystemC development.
  21. No, if you want to keep all ports in same scope you will need to follow Philipp's suggestion.
  22. My advice: start with sc_fifo, learn how it works, learn it's source code. Then write your own handshake channel using same principles.
  23. In general avoid using multiple inheritance for aggregation. It is possible, but has many drawbacks and no major benefits. Now I regret that I've written original post, but at that time I had no enough experience myself. Now, if we read any object oriented design book, we will learn that inheritance usually means "is-a" relation ship, and "has-a" relation ship is expressed by composition. Translating into HW modeling : what we want to express is that "some_module has port bundles", and not "some_module is port bundles". We can still use single inheritance in limited cases, for example if all modules in design have clock and reset, we can have a common base class like class clocked_module : public sc_module Back to your example. I recommend to convert your port bundles into modules: struct if_inputs : sc_module { sc_inout<sc_uint<4>> SC_NAMED(R_OP_MODE); sc_inout<sc_uint<8>> SC_NAMED(R_PRESET_MANUAL); if_inputs(sc_module_name){} }; struct if_outputs : sc_module { sc_inout<sc_uint<2>> SC_NAMED(T_BIT); sc_inout<sc_uint<4>> SC_NAMED(T_OP_MODE); sc_inout<sc_uint<8>> SC_NAMED(T_PRESET_MANUAL); if_outputs(sc_module_name){} }; And now you can aggregate any number of them inside monitor. Even have a vector of port bundles: class monitor : public sc_module { public: if_inputs SC_NAMED(sim_inputs); if_outputs SC_NAMED(sim_outputs); if_inputs SC_NAMED(stub_inputs); if_outputs SC_NAMED(stub_outputs); sc_vector<if_inputs> SC_NAMED(inputs_vector, 3); monitor(sc_module_name name_); private : // implementation details };
  24. SystemC standard does not guarantee any order of process evaluation within a single delta cycle. So in first example both 2,4 and 4,2 will be correct.
  25. They are in namespace sc_core. If you don't want to use namespaces you can change #include <systemc> to #include<systemc.h> and it will pull everything into global namespace.
×
×
  • Create New...