Jump to content

Roman Popov

  • Content count

  • Joined

  • Last visited

  • Days Won


Everything posted by Roman Popov

  1. The problem is that both sockets are binded to same target interface implementation. So: In[0].get_interface() == In[1].get_interface(); When you bind same interface twice to a single port, SystemC considers this a design error. Solution depends on your modeling needs. Usually TLM sockets are connected point-to-point and to model interconnect a separate module that forwards transactions from initiator to targets is created.
  2. You can use sc_vector: sc_vector<tlm_utils::multi_passthrough_initiator_socket<Router, 32, tlm::tlm_base_protocol_types,1,sc_core::SC_ZERO_OR_MORE_BOUND >> Out{"Out", 10};
  3. No, this is not allowed by SystemC LRM "5.3.3 Constraints on usage":
  4. What do you want exactly? Can you use sc_vector<My> that automatically initializes names? Can you concatenate name and ID before module construction? SystemC elaboration relies on the fact that sc_module_name will be constructed before module. This way it can create correct hierarchical names for module fields. Modern way to declare module is like this: struct my_module : sc_module { my_module(sc_module_name) { } }; More compact way is to use SystemC macros: SC_MODULE(my_module) { SC_CTOR(my_module) { } };
  5. SC_METHOD Eception

    I mean a small complete code sample I can run on my computer to reproduce the your error.
  6. SC_METHOD Eception

    No, I don't see problems in your code. It can be a problem with your visual studio settings, since expection you get comes from vs runtime. Can't help without reproducer.
  7. SC_METHOD Eception

    I don't see a problem in a given code sample. Can you provide a small complete reproducer for problem?
  8. 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.
  9. 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.
  10. 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.
  11. 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
  12. 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); }
  13. 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.
  14. 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);
  15. 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.
  16. 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?
  17. 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
  18. 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; }
  19. 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.
  20. 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.
  21. 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.
  22. 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.
  23. Explicit parent object

    Interestingly, I just encountered an HLS design that relies on dynamic ports creation in class methods. As a result sc_object names hierarchy is totally messed-up. But design is synthesizable and working! Even more: looks like HLS tools do not support phase callbacks. So probably it would be still a good idea to standardize hierarchy scope guard.
  24. SystemC and latency simulation

    If your pipeline is simple, like: get data -> process data -> put data, without I/O operations on internal pipeline stages, then you can model latency while keeping throughput: just put output data into fifo-like channel that will delay output for N cycles.
  25. SystemC and latency simulation

    No, there is no elegant way to simulate pipelines in SystemC. Commonly you just write a separate thread for each pipeline stage. Like you will do in Verilog/VHDL. 1) All HLS tools I've used do not convert SC_METHODs to pipelines. Only SC_THREADs can be converted to pipelines, if they follow some vendor-specific restrictions. 2) Yes, you can simulate latency by adding wait(N) to clocked SC_THREAD. However it will not simulate throughput. In general, this is a well known problem that HLS-generated code changes timing (expressed in clock cycles) of design. So HLS-generated code can even fail in tests that were working on input SystemC code. To avoid this, your inter-thread communication mechanisms should not depend on latency and throughput of generated hardware. You can also create latency/throughput constraints for HLS tool.