Jump to content


Popular Content

Showing content with the highest reputation since 10/19/2019 in Posts

  1. 2 points
    Your sc_trace function is a member function of the TraceList class and cannot be called like the sc_trace functions coming with the SystemC reference implementation. Those are free functions in the sc_core namespace. Moreover your sc_trace implementation is non-static so it cannot be used without a TraceList object. You need to move the function out of the class scope. Basically this is a valid approach to setup complex types. But under performance considerations I would suggest to use a different container. Best choices are std::vector or std::dqueue. And if you are using C++ 11 I would replace the while loop with a range based loop, something like: for(auto& val: var.lst) { // use namespace, compiler otherwise chooses wrong function sc_core::sc_trace(tf, val, nm + std::to_string(pos++)); }
  2. 1 point
    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 }
  3. 1 point
    Looks like XY problem to me. If you need pointer to event, use pointer.
  4. 1 point
    Roman Popov

    sc_fifo data_read_event

    Did you probably forget to add wait() into consumer thread to suspend it after first read?
  5. 1 point
    No, if you want to keep all ports in same scope you will need to follow Philipp's suggestion.
  6. 1 point
    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 };
  7. 1 point
    You have multiple instances of the "bundles" in your monitor class: inherited directly as additional members in the nested classes sim and stub To avoid the name clashes, you can make sim and stub modules themselves via: struct sim : sc_module , if_inputs, if_outputs { SC_CTOR(sim) {} } sim { "sim" };
  • Create New...