Philipp A Hartmann

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

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

You might want to read this "C++ Super FAQ" entry: https://isocpp.org/wiki/faq/templates#templates-defn-vs-decl Hope that helps, Philipp

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

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

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

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

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

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

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

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

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

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

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

You can chose whatever name you want in the target. You just register them to different sockets: // register different functions for each socket socket1.register_b_transport(this, &target::first_b_transport); socket2.register_b_transport(this, &target::second_b_transport); // in testbench, call b_transport on different sockets (assuming init_socket1/2 bound to target->socket1/2) init_socket1->b_transport(...); // will call target::first_b_transport init_socket2->b_transport(...); // will call target::second_b_transport /Philipp

But the above code should work. Just call "b_transport" (not "first_b_transport" and "second_b_transport") from your testbench. /Philipp

Why do you try to call b_transport_2(...) anywhere in your code? How do you register these functions to the simple socket? /Philipp

Your current implementation still depends on the scheduling order of the simulation kernel: If the mutex is not locked, the first scheduled process will obtain the lock, irrespectively of any current or future locking attempts in the same evaluation phase. For example, if one process repeatedly tries to lock the mutex directly after releasing it, the lock will be granted, even if there are other processes already waiting: void procA() { while(true) { mtx.lock(); // do some work wait( 10, sc_core::SCNS ); mtx.unlock(); // will get the lock back again immediately! } } void procB { // ask for the lock slightly later wait( 5, sc_core::SC_NS ); // continue as procA procA(); } In order to fix it, you'll at least need to check the queue before granting the lock (untested): while (s_queue.front() != sc_get_current_process_b() || in_use()) { sc_core::wait(m_free); } That said, you should not be using the implementation-defined sc_process_b class and use sc_process_handle and sc_get_current_process_handle() instead, to be more standards-compliant. Hope that helps, Philipp

SystemC Evolution Day 2017 Workshop on the evolution of SystemC standards Wednesday, October 18, 2017 Munich, Germany Summary SystemC Evolution Day is a full-day technical workshop on the evolution of SystemC standards to advance the SystemC ecosystem. This is the second event after a successful first edition in May 2016. In several in-depth sessions, current and future standardization topics around SystemC will be discussed in order to accelerate their progress for Accellera and IEEE standard’s inclusion. SystemC Evolution Day is intended as a lean, user-centric, hands-on forum bringing together the experts from the SystemC user community and the Accellera Working Groups to advance SystemC standards in a full-day workshop. Date / Time: October 18, 2017 (day after DVCon Europe 2017) | 10:00am - 6:00pm Location: Technical University of Munich, City Campus | Arcisstraße 21, 80333 Munich, Germany Registration: Required, but free of charge. Register here > Submissions / Questions: Email systemc-evolution-day@lists.accellera.org Organization Team: Philipp A Hartmann, Intel; Oliver Bell, Intel; Martin Barnasconi, NXP; Matthias Bauer, Infineon; Thomas Kruse, Infineon Call for Contributions In the morning, a series of lightning talks are planned, covering concrete, but smaller standardization proposals as well as introducing new standardization needs around SystemC. For each of these short presentations, time for an interactive discussion will be included to gather feedback and support and for identifying the next steps towards standardization. In the afternoon, in-depth topic sessions are planned again, enabling a 90-minute detailed and interactive technical discussion on the most significant ongoing and future topics around SystemC standardization. If you are interested in championing a topic for an afternoon session or presenting your favorite extension to the SystemC community as part of a lightning talk, please send a title and abstract with up-to 100-words (lightning talks) or 400 words (topic session) by end of June to systemc-evolution-day@lists.accellera.org. You will receive a notification of acceptance by September at the latest. Important dates: June 30, 2017 – Proposal abstract submission deadline September 1, 2017 – Notification of acceptance September 15, 2017 – Announcement of the program

Hi Veena, When you use simple_target_socket instances as described in the snippet above, you still call the normal b_transport on the initiator side. Can you show more context of the problem? Greetings from Duisburg, Philipp

Hard to tell without details about what exact cast (i.e. between which types) is invalid. My guess would be the use of an array instead of the individual ports. /Philipp

Third point: You're using a C-style array of ports, which won't work either. You should use an sc_vector (to name your ports) and use a loop to add the sensitivity (if you want to be sensitive to all ports in the vector): // change member sc_core::sc_vector< sc_core::sc_fifo_in<int> > in; // constructor scMWE::scMWE(sc_core::sc_module_name nm) : sc_core::sc_module(nm) , in("in", 4) // initialize vector { SC_METHOD(WritePseudo); for( auto& in_x : in ) // or a plain loop over the elements, if you don't have C++11 sensitive << in_x.data_written(); } /Philipp

Oh, and I just realized, that your in port is an sc_fifo_in<int>, which doesn't have a default event (IIRC). You probably want to use the data_written event finder instead: sensitive << in.data_written(); Hope that helps as well, Philipp

Hi Katang, your process function takes a parameter (int A). This is not supported for SC_METHOD et.al. Hope that helps, Philipp