Jump to content

Philipp A Hartmann

  • Content Count

  • Joined

  • Last visited

  • Days Won


Everything posted by Philipp A Hartmann

  1. Philipp A Hartmann

    Passthrough Module -- Fifo Implementation

    The model you describe is not "just" a passthrough model though, as you assume that tokens can be both intercepted (other processes reading from incoming_fifo) and injected (other processes than B writing to outgoing_fifo). From my experience, it is very difficult to design robust models with multiple readers and writers for FIFOs, at least without higher-level synchronization orchestrating the accesses somehow. That said, let's assume these arbitrary FIFO accesses are needed and OK for your use case. I would suggest to indeed use the non-blocking APIs to do the forwarding: while( true ) { if( incoming_fifo.num_available() > 0 && outgoing_fifo.num_free() > 0 ) { // forwarding possible, process token - will never block outgoing_fifo.write( incoming_fifo.read() ); } // at least one side is blocking, wait for activity on either side wait( incoming_fifo.data_written_event() | outgoing_fifo.data_read_event() ); } This will not lead to an additional implicit slot in the passthrough block, but the forwarding is "non-greedy" now, i.e. happens only if a slot is available on both sides. Together with arbitrary other readers/writers on the FIFOs, your passthrough model might never succeed to forward a single token. See above. Minor comment: Your thread_A pseudo code above looks like Java/SystemVerilog and would have a memory leak in C++. You should not put dynamically allocated objects into a FIFO. Hope that helps, Philipp
  2. Philipp A Hartmann

    problems regresson tests

    When you use MSVC 2015/2017, did you make sure to use SystemC 2.3.2? Earlier SystemC versions did not support such recent versions of MSVC. When you say "regression tests", do you mean the SystemC regression test suite? If so, please check the accompanying README_windows.txt for any steps you might have missed. If this still doesn't help, please post some more details on what exact errors you see. Greetings from Duisburg, Philipp
  3. Philipp A Hartmann

    how do I terminate all threads at end of simulation ?

    Ok, now I understand your concern: It's also about stack-allocated variables in your threads that are not cleaned up at the end of the simulation, as their stacks are not unwound and dynamic process stacks may not even be explicitly deallocated. I'm not sure, if these cases qualify as real memory leaks, though. Small comment: instead of throwing an (non-standard) sc_halt object, you can simply call : h.kill(SC_INCLUDE_DESCENDANTS); // also kills all child processes There is currently no way to obtain (or kill) all running processes in the simulation, but you can roll your own function to recurse over the object hierarchy via get_child_objects() convert objects to process handles, if valid() and !terminated() call kill(SC_INCLUDE_DESCENDANTS) /Philipp
  4. Philipp A Hartmann

    Explicit parent object

    If you invert the logic and add a function add_initiator to the interconnect, temporarily storing the pointer to the to-be-connected initiator socket (and maybe a name, although this can be derived from the given socket or its parent), you can complete the binding and target socket creation in the interconnect's before_end_of_elaboration hook. Sockets instantiated in this function will be placed correctly in the hierarchy and this approach is fully standards-compliant.
  5. Philipp A Hartmann

    Install SystemC on Visual Studio 2017

    Starting with SystemC 2.3.2, the MSVC project files shipped with the package use the DLL-based runtime library. Therefore it is not necessary (instead rather harmful) to select the statically linked runtime library in your application. Secondly, you should not set the SC_SIGNAL_WRITE_CHECK environment variable to DISABLE (unrelated to your current issue, but suggested in the video above). More instructions on using MSVC with SystemC can be found in the INSTALL file shipped with the proof-of-concept simulator. Hope that helps, Philipp
  6. Philipp A Hartmann

    Explicit parent object

    As said above, for the TLM-2.0 interconnect case, you can just use multi sockets on don't add additional sockets to the interconnect model at all. My question hasn't been on the "surrounding side", but on the usage of the sockets inside the interconnect and the cpu/mem/uart models. Thes modules actually have to make use of the "injected sockets", which likely requires some additional hacks. How does the memory handle a second "tgt()" socket during simulation? How does the CPU suddenly leverage a second initiator?
  7. Philipp A Hartmann

    how do I terminate all threads at end of simulation ?

    While most of the things in the referenced discussion still hold, we slightly extended the "thread cleanup" in the recently released SystemC 2.3.2. Can you please try, if the behavior improves when using the new version? Thanks, Philipp
  8. Philipp A Hartmann

    Explicit parent object

    To me, this approach still looks backwards. If you need to finalize things in the model after the configuration is complete (e.g. spawning threads, etc), you can use the before_end_of_elaboration hook. You can even do the instantiation itself there, if needed, by just storing the pointer to the master and doing both instantiation and process spawning during before_end_of_elaboration. Adding emplace_back to sc_vector would just reduce the boilerplate of the delayed instantiation of structural members. But there are already ways to achieve all of this without any changes to the language.
  9. Philipp A Hartmann

    Explicit parent object

    Both versions are non-portable, as the SystemC simcontext is not part of the standard either. I am even surprised that the hierarchy_push/pop functions are not restricted (as they should be). So the first solution might in fact break in future versions of SystemC as you shall not mess with the object hierarchy stack yourself. Whether or not the "hierarchy scope guard" can be extended to become a standardized solution will likely require some discussions first, especially how to avoid breaking the object hierarchy. Certainly, this internal hierarchy stack is not something to arbitrarily use from the model side, other than from the sc_module_name usage today. For the particular use case, you can now look into the new "optionally bound convenience sockets" in SystemC 2.3.2, which you can safely leave unbound when not used. An arbitrary number of sockets can be bound to the multi_passthrough_*_socket, without having to do any such magic above. For a generic pattern to request additional structural things to "appear later", you can use an sc_vector with delayed initialization (since SystemC 2.3.2). This is (currently) limited to a single call, but I could envision to extend this to support distributed emplace_back() calls during elaboration. Such an approach would at least restrict the external modification of the hierarchy to much more controllable contexts. Regarding your current use case: How does the destination module actually use these newly added ports/sockets? /Philipp
  10. Philipp A Hartmann

    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
  11. Philipp A Hartmann

    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
  12. Philipp A Hartmann


    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
  13. Philipp A Hartmann

    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
  14. 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
  15. 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
  16. Philipp A Hartmann

    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
  17. Philipp A Hartmann

    sc method over sc thread

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

    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
  19. Philipp A Hartmann

    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
  20. Philipp A Hartmann

    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
  21. Philipp A Hartmann

    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
  22. Philipp A Hartmann

    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
  23. Philipp A Hartmann

    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
  24. Philipp A Hartmann

    SystemC Evolution Day 2017

    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
  25. Philipp A Hartmann

    SystemC Evolution Day 2017

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