Jump to content

Roman Popov

  • Content count

  • Joined

  • Last visited

  • Days Won


Everything posted by Roman Popov

  1. std::vector as template argument

    Templates are compile time feature in C++. So you can't use values that are not compile-time constants as non-type template parameters. Instead use a constructor parameter to pass arguments: SC_HAS_PROCESS(select_unit); select_unit(::sc_core::sc_module_name name, std::vector<unsigned> &sbits) : sel_bits(sbits) { /*...*/ } std::vector<unsigned> &sel_bits;
  2. Explicit parent object

    My understanding is that it does not solves the problem with processes. In the past I was using this technique in RTL verification, to add ports to fabric verification model on request. And very often you need to add a process that will handle bus protocol. Pseudocode: add_slave_port ( master_type *master ) { sc_object::hierarchy_scope scope(this); slave_port_vector.emplace_back bind_master_to_slave spawn_protocol_service_thread } In general you need a separate process for each port, because protocols can be multicycle and each port can be in a different state. But I agree that emplace_back for sc_vector will be more convenient than using regular vector of pointers.
  3. 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"))); }
  4. 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.
  5. 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.
  6. 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.
  7. 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.
  8. 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>
  9. 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
  10. 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.
  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. 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.
  13. 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.
  14. unresolved external

    No, inlining should not be mandatory https://gcc.gnu.org/onlinedocs/gcc-3.1/gcc/Template-Instantiation.html
  15. 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?
  16. 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.
  17. 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.
  18. Execution Trace Generation

    Can you clarify what do you mean by execution trace?
  19. Temporal Decoupling

    My suggestion would be to implement this example and see what happens. In a process you will learn most of TLM-2.0 concepts.
  20. multiple SC_THREAD inside one Module

    Yes. You can exclude some process from initialization phase by calling dont_initialize() after creating process. For example: SC_METHOD(methodOne) ; sensitive << terminateMethod_ev ; dont_initialize();
  21. multiple SC_THREAD inside one Module

    Hello, All the answers can be found in standard: http://standards.ieee.org/getieee/1666/download/1666-2011.pdf Questions are tricky, so it's hard to guess answers without reading documentation carefully. Especially: Afaik, standard does not prohibit running processes in parallel, in case it is invisible to user. So implementation of standard can run some processes in parallel. But Accellera opensource SystemC implementation is single-threaded.
  22. TLM 1.0 => TLM 2.0

    Yes, I do this kind of conversion of TLM-1.0 to TLM-2.0 and vice versa very often, because for synthesis only TLM-1.0 is supported, and for VP TLM-2.0 is commonly used. The converter will be application-specific, because TLM-1.0 has no standard payload (Many TLM-1.0 models even define their own interfaces, instead of using standard put/get ).
  23. Hello, I need to port following code from Verilog to SystemC: assign #DELAY out = in; What is the best known method to do this in SystemC? Similar question on stackoverlow https://stackoverflow.com/questions/5566785/specifying-signal-delays-in-systemc-as-clause-after-in-vhdl
  24. How to model a delay line in SystemC

    I've needed it for test environment modeling purposes, not for synthesis. Delta delay problems (also known as Shoot-thru) are possible in synthesizable SystemC. Common case is when you have a clock gate that inserts a delta delay into a clock signal distribution network. However in SystemC it is solved in a different way: Instead of delaying all assignments, you use immediate notifications inside clock signal, so that processes sensitive to gated clock are executed in the same delta cycle with processes sensitive to ungated clock.
  25. -isystem libs/systemc-2.3.1a/include This line looks suspicious. Should not it be something like -I/path/to/systemc/include ?