Jump to content

Philipp A Hartmann

  • Content count

  • Joined

  • Last visited

  • Days Won


Philipp A Hartmann last won the day on September 5

Philipp A Hartmann had the most liked content!

1 Follower

About Philipp A Hartmann

  • Rank
    Advanced Member

Profile Information

  • Gender
    Not Telling
  • Location
    Duisburg, DE

Recent Profile Visitors

934 profile views
  1. Converting sc_signal<T1> to sc_signal<T2>

    Any eventual copy returned from read() by value will never be optimized away, as the source location continues to exist in the signal. The simplest solution is to change your signal converter as follows (untested): template <typename Treal, typename Tcasted> class signal_interface_converter : public sc_core::sc_signal<Treal> , public sc_core::sc_signal_in_if<Tcasted> // only read allowed { typedef sc_core::sc_signal<Treal> real_type; public: explicit signal_interface_converter(const char* nm) : real_type(nm), casted_val() {} const Tcasted &read() const override { return casted_val; } private: void update() override { real_type::update(); casted_val = static_cast<Tcasted>(real_type::read()); ] Tcasted casted_val; }; So the idea is basically to leverage the update phase to update the casted value. If the above doesn't work due to read() overloads based on the return type only, you may need to wrap it differently to separate the two conflicting interfaces (e.g. by using an internal signal with an overridden update() function, triggering the update of the casted value in the converter). Hope that helps, Philipp
  2. Problems using sca_tdf::sc_in<bool>

    My crystal ball guess would be the linker ordering between -lsystemc and -lsystemc-ams. Please make sure to put -lsystemc right of -lsystemc-ams in your linker command. Can you share the build setup, especially the final linker command line? /Philipp

    Two things are to be noted here: IEEE 1666-2011 added support for writer policies, IEEE 1666-2005 required to have conflict detection. So keeping the default behavior was a natural choice back then SC_DEFAULT_WRITER_POLICY is not part of the IEEE Std. 1666-2011, but an extension in the proof-of-concept implementation Last but not least, you can always use your own signal template alias: template<typename T> using sc_signal_mw = sc_core::sc_signal<T, sc_core::SC_MANY_WRITERS> Hope that helps, Philipp
  4. unresolved external

    You might want to read this "C++ Super FAQ" entry: https://isocpp.org/wiki/faq/templates#templates-defn-vs-decl Hope that helps, Philipp
  5. You would need to describe your actual question in a bit more detail. Is it about the logic inside the target (i.e. not performing the write)? Sure, you can check the state of the control bit in b_transport before processing the command. Is it about informing the initiator that this happened? Then you need to either use the response status or an extension. /Philipp
  6. Your options depend on what you mean by "reject/block". For example, you can reject the transaction by setting an error response in the transaction. See IEEE Std. 1666-2011, 14.17 for the available status codes and their meaning. // tlm::tlm_generic_payload& trans trans.set_response_status( tlm::TLM_GENERIC_ERROR_RESPONSE ); Hope that helps, Philipp
  7. Execution Trace Generation

    Hi Adiga, at the end, SystemC simulations are plain C++ programs. Therefore, you can use any program trace tool that meets your needs. One example could be the Linux perf tool, see https://perf.wiki.kernel.org. Your favorite SystemC simulator may have additional analysis features. You might want to ask your vendor about this. Hope that helps, Philipp
  8. sc method over sc thread

    I wouldn't say that in this generality. Both process types have their advantages, depending on the use case.
  9. multiple event in next trigger

    I cannot tell, if I understand your question at all. I'll just add the comment that you can use next_trigger(); without any arguments to restore the static sensitivity. Hope that helps, Philipp
  10. segmentation fault with async_reset_signal_is()

    Hi Avihai, I can confirm this behavior with the latest SystemC 2.3.2 pre-release and would classify this as a bug. As a short-term workaround, you can mark affected threads with dont_initialize(), which happens not to trigger this misbehavior: SC_THREAD(thread1); sensitive << thread1_event; async_reset_signal_is(reset_in,true); dont_initialize(); // avoid crash when starting in reset state I'll forward this issue to the Language Working Group for further analysis. Greetings from Duisburg, Phiipp
  11. Left shift with zero results in

    Can you please post a complete, self-contained example to demonstrate the issue? Reading your post, I still cannot infer what actual values, types, ... are involved and not even where you changed the "line" to sc_uint<5>. The following code works for me: #include <systemc> int sc_main (int, char *[]) { using namespace sc_dt; #define CORE_BUS_WIDTH 5 #define MASK_WIDTH 32 { sc_uint<CORE_BUS_WIDTH> id; sc_uint<MASK_WIDTH> mask(1 << id); std::cout << "id=" << id << "\t- mask=" << mask.to_string(SC_BIN) << std::endl; } { sc_uint<CORE_BUS_WIDTH> id(-1); sc_uint<MASK_WIDTH> mask(1 << id); std::cout << "id=" << id << "\t- mask=" << mask.to_string(SC_BIN) << std::endl; } return 0; } From your original error message, it looks more like an issue with MASK_WIDTH or CORE_BUS_WIDTH to me. Do you see any compiler warnings? Hope that helps, Philipp
  12. Left shift with zero results in

    Shifting by zero should of course be supported. Can you provide a self-contained example demonstrating the problem? Instead, the error message indicates, that you try to create an sc_uint<-2147483648> (or rather an sc_uint_base with the dynamic width of this value, e.g.), which is not allowed. What's the definition of MASK_WIDTH? What's the definition of ID? Hope that helps, Philipp
  13. debug problem systemc

    The error message is an indication, that you might miss the /vmg switch in your the MSVC project. Quoting from the SystemC INSTALL file (emphasis mine): Hope that helps, Philipp
  14. Usage of Sc_event_or_list

    Yes, there is currently no explicit function for this. But you can assign an empty one first: _orEvents = sc_event_or_list(); There is a caveat that this might break processes that are currently waiting for the previous elements in the list. But if you're sure that nothing is currently waiting of the list, the above example Should Work™. Hope that (still) helps, Philipp
  15. SystemC Evolution Day 2017

    Bump thread to the top: Don't forget to submit your proposals! :-)