Jump to content

Roman Popov

  • Content count

  • Joined

  • Last visited

  • Days Won


Roman Popov last won the day on March 4

Roman Popov had the most liked content!

1 Follower

About Roman Popov

  • Rank
    Advanced Member

Recent Profile Visitors

674 profile views
  1. Passing collected events to sensitive

    You can write function that will add collection of events to sensitivity. You can even overload operator << if that's what you want.
  2. Use of callback before_end_of_elaboration

    In a current implementation sc_start() finishes elaboration and starts simulation. You can look into source code for details. But at very high level you can think of sc_start like this: void sc_start() { finish_elaboration(); // complete binding, call before_end_of_elaboration start_simulation(); // start scheduler } I recommend to run sc_start() in debugger step-by-step to understand what happens inside.
  3. Use of callback before_end_of_elaboration

    No, changing the structure of design is not possible after elaboration. You can't create signals, ports and modules during simulation. But you can spawn new processes, this is commonly used in verification environments, to model different streams of test stimulus.
  4. Using Debug mode.

    I don't know how autotools flow works. But in case you can use CMake, it is very easy to complie in debug mode, just add -DCMAKE_BUILD_TYPE=Debug when generating Makefile. $ mkdir build_debug $ cd build_debug $ cmake ../ -DCMAKE_BUILD_TYPE=Debug $ make -j8 simple_fifo $ gdb ./examples/sysc/simple_fifo/simple_fifo
  5. Use of callback before_end_of_elaboration

    As I understood you want to read value from port during elaboration process? This is not how ports are supposed to be used. They are simulation-time mechanism. If you want to initialize a vector with some value, why don't you just pass it as a constructor parameter? sub_module(::sc_core::sc_module_name, int a ) { b.init(a); }
  6. Debugging Multi threaded program in SystemC

    SystemC does not execute your threads in parallel, they are executed sequentially. But this is true that inter-thread communtication is hard to debug. Best known debugging method is waveform analysis. Usually it is much faster to identify source of problem on waveform, rather than with text logs. With opensource kernel you can use sc_trace to trace variables. Commerical SystemC debuggers offer GUI with drag-and-drop support.
  7. Backtrace with sc_report_error()

    Did you checked SystemC standard? 8.3 sc_report_handler. You can try doing it like this: void my_handler(const sc_report& r, const sc_actions & a) { sc_report_handler::default_handler(r,a); } sc_report_handler::set_handler(my_handler);
  8. SC_METHOD and next_trigger() diagnostics

    Can you give a complete small reproducer of your problem? Otherwise I can just guess. Who calls getByte? Some sc_thread? About SC_HAS_PROCESS - it should be fine unless you defne couple of modules in same translation unit.
  9. SC_METHOD and next_trigger() diagnostics

    Most likely you are calling WaitAccessing from somewhere else, not shown in your code sample. Just set a breakpoint on error and check call stack. Also, why do you put SC_HAS_PROCESS to global namespace?
  10. Backtrace with sc_report_error()

    If you want to see stacktrace in LLDB, then just set a breakpoint in sc_report_error(). If you want to see a stacktrace when you run simulation without debugger, then use Boost::Stacktrace http://www.boost.org/doc/libs/1_65_1/doc/html/stacktrace.html
  11. parametric 3 state buffer

    Most likely the problem is that you don't have enough expertise in C++. SystemC is rather advanced C++ library, so should read a good C++ book before approaching SystemC. Try to understand what is the difference between "Z" and 'Z' (notice quotation marks). Also read sc_signal_rv documentation in SystemC standard pdf. Here is a small example to show how sc_signal_rv works: #include <systemc.h> struct test : sc_module { sc_signal_rv<4> sig_rv{"sig_rv"}; SC_CTOR(test) { SC_THREAD(test_thread0); SC_THREAD(test_thread1); } void test_thread0 () { sig_rv = "Z10Z"; wait(1,SC_NS); cout << sig_rv << endl; } void test_thread1 () { sig_rv = "Z0Z1"; } }; int sc_main(int argc, char **argv) { test t0{"t0"}; sc_start(); return 0; }
  12. parametric 3 state buffer

    I just wanted to say that you code compiles, just probably won't do what you expect, because char 'Z' will be implicitly casted to int. In case you have compiler errors, please post them here.
  13. parametric 3 state buffer

    Do you mean you have : This will compile: sc_signal_rv<W>::write takes sc_lv<W> as a parameter, that can be implicitly constructed from int. So your 'Z' (ASCII code 90) will be converted to int 90, that is probably not what you wanted.
  14. reset during wait(int)

    Most likely the problem is that cthead suspended with wait(n) ignores reset. So yes, this can be a problem with reference implementation.
  15. SystemC 2.3.2 installation error

    Your compiler is broken, cmake won't help here. It looks like you are using compiler that was not built for your OS version.