Jump to content

Roman Popov

  • Content count

  • Joined

  • Last visited

  • Days Won


Roman Popov last won the day on August 14

Roman Popov had the most liked content!

1 Follower

About Roman Popov

  • Rank
    Advanced Member

Recent Profile Visitors

354 profile views
  1. Explicit parent object

    Update: In sysc/kernel/sc_object_int.h there is a scope guard (https://stackoverflow.com/questions/31365013/what-is-scopeguard-in-c) for this particular case. So it is possible to rewrite code in previous answer like this: #include <systemc.h> #include <sysc/kernel/sc_object_int.h> ... struct bottom : sc_module { ... void add_input() { sc_object::hierarchy_scope scope(this); inputs.emplace_back(std::make_unique<sc_in<bool>>(sc_gen_unique_name("input"))); }
  2. Explicit parent object

    It is possible, but : Not standardized Requires knowledge of SystemC kernel internals If it's ok for you, take a look on sc_object::sc_object_init (sc_object.cpp) to understand how it is created. Now you can try something like this: (I'm creating sc_in ports, instead of tlm sockets here): #include <systemc.h> struct bottom : sc_module { std::vector<std::unique_ptr<sc_in<bool>>> inputs; void add_input() { sc_get_curr_simcontext()->hierarchy_push(this); inputs.emplace_back(std::make_unique<sc_in<bool>>(sc_gen_unique_name("input"))); sc_get_curr_simcontext()->hierarchy_pop(); } SC_CTOR(bottom) { } }; struct top: sc_module { bottom b{"b"}; SC_CTOR(top) { b.add_input(); b.inputs[0]->bind(bsig); b.add_input(); } sc_signal<bool> bsig; }; int sc_main(int argc, char** argv) { top t{"t"}; sc_start(); return 0; } If you run it, you will have an error message with correct hierarchical name: Error: (E109) complete binding failed: port not bound: port 't.b.input_1' (sc_in) I think your usage case is legitimate and we need to think of standardizing some solution.
  3. Question about cout and time

    In Accellera SystemC you can use simulation time callbacks. Check systemc/RELEASENOTES : ( Experimental features - Extended Simulation Phase Callbacks ). You will need SC_BEFORE_TIMESTEP callback. But they are not yet part of IEEE standard, so portability is not guaranteed.
  4. SystemC for virtual prototype ARM based SOC

    If you need something opensource for learning than you can try GreenSocs examples (https://www.greensocs.com/get-started) . For commercial models contact you IP vendor.
  5. Converting sc_signal<T1> to sc_signal<T2>

    Yes, but in most cases copy is not created , but used as rvalue in computations. Most likely end user can do something like: auto val = some_signal.read(); that also creates a copy anyway. Great idea. Unfortunately it is not possible to apply it for hierarchical bindings, that are also quite common case where type conversion happes, i.e. when you bind sc_in<T1> to sc_in<T2>
  6. Microsoft Visual Studio Community 2015

    What exactly does not work for you? Did you tried 2.3.2 draft? http://www.accellera.org/downloads/drafts-review
  7. Converting sc_signal<T1> to sc_signal<T2>

    Hi Ralph, Compiler should optimize a copy when possible. So it should not be a performance bottleneck. Its not my problem, but it is a problem in general. A write-through to temp_val will be a SC_METHOD sensitive to value_change_event(). This will be a performance problem when a lot of traffic goes through such a converter Yes, this is another issue.
  8. Hello, I need to connect Verilated model into SystemC testbench . Testbench was written for bit-accurate types like ( sc_in<sc_int<exact_bus_width> > ). Verilator uses sc_in<uint32_t> and sc_in<uint64_t> for all buses that are under 64 bits in width. How can I efficiently convert between two? I know there is a solution with additional SC_METHOD that converts from T1 to T2, but it is unfortunately affecting simulation performance, since I'm introducing another method and signal to design. Instead I've implemented converter from sc_signal_inout_if<T1> to sc_signal_inout_if<T2> and it worked fine for my simulation. But there is a potential problem with a read() method, since it returns a reference: template <typename Treal, typename Tcasted> class signal_interface_converter : public sc_signal_inout_if<Tcasted> { const Tcasted &read() const override { temp_val = host_ptr->read(); return temp_val; } private: Tcasted temp_val; sc_signal_inout_if<Treal> * host_ptr; } In Verilator integration context it looks safe: Verilator converts whole design into a single SC_METHOD so it should not reuse reference between different delta cycles. However in general I can write a code like that: auto & address_ref = addr_signal.read(); wait(); memory[address] = 42; // address_ref may have changed after wait. So basically returning value by reference in read() disables a potential optimization for sc_signal converters :( And the benefits of returning a reference are not clear to me.
  9. Ok, what I've learned that in SystemC 2.3.2 default can be overridden in runtime. So it should close the issue once released.
  10. I have used two SystemC HLS synthesis tools in practice: First one had SC_MANY_WRITERS as default. So every sc_signal<T> is in fact sc_signal<T,SC_MANY_WRITERS> in this tool Second tool allows synthesis of sc_signal<T,SC_MANY_WRITERS> SC_MANY_WRITERS is safe for synthesis and have a clearly defined representation in multiple SC_CTHREAD drivers case: a register with a multiplexer. Unlike SC_UNCHECKED_WRITERS, when two SC_CTHREADS write to signal in same delta cycle error will be detected and reported. I agree that two SC_METHODs driving same sc_signal has no clear HW representation. Test-benches are main reason why I think it should be SC_MANY_WRITERS by default. In testbenches sc_spawn dynamic processes are commonly used to model complex test scenarios. As soon as dynamic thread touches sc_signal your simulation immediately fails. So you have two options: Manually replace all top-level DUT pins to sc_signal<T, SC_MANY_WRITERS> Compile with SC_MANY_WRITERS by default. Most likely users will chose second path. So why not making it as default? Verilog/SystemVerilog has "SC_MANY_WRITERS" by default and I don't hear any complains about it (multiple drivers are detected by synthesis tools, but is ok for SV testbenches). Verilog authors in theory can make "SC_ONE_WRITER" behavior a default and offer some keyword to override it. But no one asks for it. So in my view common industry knowledge is that SC_MANY_WRITERS by default is ok. Because there are so many practical cases when you need it.
  11. Hello, Why SC_MANY_WRITERS is not default SC_DEFAULT_WRITER_POLICY in SystemC? In my opinion SC_ONE_WRITER does more harm then profit. Sooner or later every user faces the fact that he will need to change this default during the SystemC compilation. So why not to change it out-of-the-box?
  12. unresolved external

    No, inlining should not be mandatory https://gcc.gnu.org/onlinedocs/gcc-3.1/gcc/Template-Instantiation.html
  13. unresolved external

    If you put template <unsigned in_width, unsigned x_pe16> void lzd_unit<in_width, x_pe16>::thread0(void) { ... } in lzd_unit.h instead of lzd_unit.cpp Does this fix the error?
  14. Execution Trace Generation

    Another option would be to write a python script for gdb that will automate the process. It's not hard in my experience, probably will take 2-3 weeks to implement. https://sourceware.org/gdb/onlinedocs/gdb/Python-API.html Drawback is that it would be simulating quite slowly.
  15. colossal LNK2001 & LNK2019 errors

    Try to check if all MSVC flags are consistent between SystemC solution and your application solution. Common issue is runtime library flags.