Jump to content

Philipp A Hartmann

Members
  • Content Count

    482
  • Joined

  • Last visited

  • Days Won

    115

Everything posted by Philipp A Hartmann

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

    SystemC Evolution Day 2017

    Bump thread to the top: Don't forget to submit your proposals! :-)
  3. Philipp A Hartmann

    multiple b_transport methods

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

    multiple b_transport methods

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

    multiple b_transport methods

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

    implementing a fair mutex

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

    multiple b_transport methods

    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
  8. 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
  9. 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
  10. 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
  11. Hi Katang, your process function takes a parameter (int A). This is not supported for SC_METHOD et.al. Hope that helps, Philipp
  12. Philipp A Hartmann

    Clocked thread SC_CTHREAD exclusion during initialization phase

    No. These process flavors are subject to the dont_initialize() setting. See IEEE 1666-2011, 4.2.1.1, step (b): Greetings from Duisburg, Philipp
  13. Philipp A Hartmann

    Clocked thread SC_CTHREAD exclusion during initialization phase

    Because clocked threads are sensitive to an explicit clock. This clock does not have to be active during the start of the simulation. Greetings from Duisburg, Philipp
  14. Philipp A Hartmann

    Dynamic processes and initialization phase

    Yes, creating a process with dont_initialize() set just keeps it off the runnable queue until it is triggered by its static sensitivity (or through an explicit reset() on a process handle of it). Without dont_initialize(), static process are marked as runnable during the initialization phase, while dynamic processes are made runnable immediately (i.e. in the current/next evaluation phase). Hope that helps, Philipp
  15. Hi Antonio, as I understand it, the SystemC AMS proof-of-concept implementation is now provided by COSEDA, see http://www.coseda-tech.com/systemc-ams-proof-of-concept Hope that helps, Philipp
  16. Philipp A Hartmann

    Scope of SC_HAS_PROCESS

    Recommended practice is to put SC_HAS_PROCESS within the scope of the module itself: SC_MODULE(Module) { SC_HAS_PROCESS(Module); // ... }; Hope that helps, Philipp
  17. Philipp A Hartmann

    How to implement parent-child relationship?

    For an up-to-date documentation of SystemC, please refer to the IEEE Std. 1666-2011, available free of charge (thanks to the Accellera Systems Initiative) from http://standards.ieee.org/getieee/1666/download/1666-2011.pdf.
  18. Philipp A Hartmann

    systemC on visual studio 2015

    Try using the current public review release of SystemC 2.3.2 (see the following announcement): This version has been tested successfully on Visual Studio 2015. Hope that helps, Philipp
  19. Philipp A Hartmann

    SystemC 2.3.2 Public Review Now Open

    Hi Ameya, thanks for testing the 2.3.2 public review release! You mentioned, that you saw 15 errors when running the regressions on your platform? Would it be possible to share the list of failing tests and your platform/compiler versions? As you may have seen, I have opened a new topic about your C++ standard question here: Thanks for the analysis and the reporting of the issue. I have prepared a fix for the 2.3.2 final release which avoids the need for the synthesis of the ..._FILTER variable in test script. Instead, the optional filter is substituted directly from within the Makefile and GNU make supports variables starting with a digit. This topic is under discussion since quite some time both inside and outside of Accellera. The best option to contribute patches/fixes to the SystemC proof-of-concept implementations is of course to join the corresponding Accellera Working Groups. If this is not an option, let's continue to use this community forum for public discussions around SystemC and its proof-of-concept implementation. Greetings from Duisburg, Philipp
  20. Philipp A Hartmann

    Fail to install SystemC 2.3.1 on OpenSUSE Tumbleweed

    Hi Ahmed, apologies for the late reply. This is indeed an surprising behavior on your system. It seems the default "--libdir" setting from Autoconf is different on your platform - which is not expected. Can you please post the output of running ../configure --help In order to create the canonical "classic installation layout" of SystemC, you can override the --libdir default via (please note the single quotes): ../configure --libdir='${prefix}/lib' I'll look into the TESTNAME incompatibility for the final 2.3.2 release as well. Thanks and Greetings from Duisburg, Philipp
  21. Philipp A Hartmann

    Support for C++11/14 in SystemC 2.3.2

    Hi Ameya, you're right: The SystemC 2.3.2 release selects a particular C++ standard to build upon and enforces consistency of this selection between the model and the library at link-time. Users can override the detection by setting the SC_CPLUSPLUS macro at build time to a (usually earlier) C++ version, as documented in the RELEASENOTES and INSTALL files of the SystemC 2.3.2 public review release. RELEASENOTES: 5) Initial support for C++11/14 =============================== This package includes an initial implementation of the C++11/14 proposal, presented at DVCon Europe 2016 ("Moving SystemC to a new C++ Standard"). This includes the addition of two new preprocessor symbols: - IEEE_1666_CPLUSPLUS (read-only) This symbol indicates the availability of certain SystemC features which depend on a particular version of the ISO C++ standard (see below). - SC_CPLUSPLUS (overridable) By default, the most recent supported version of the C++ standard for the current platform/compiler is automatically detected and reflected by the SC_CPLUSPLUS macro. Users can override (i.e. usually downgrade) the assumed C++ standard to an earlier version for compatiblity. The value of this macro has to be set consistently across the SystemC library build and all linked models (see INSTALL). The values of these macros follow the values defined by the C++ standards. Currently supported versions are: - 199711L (C++03, ISO/IEC 14882:1998, 14882:2003) - 201103L (C++11, ISO/IEC 14882:2011) - 201402L (C++14, ISO/IEC 14882:2014) The following features currently require a dedicated C++ standard version beyond ISO/IEC 14882:2003 (aka C++03): - C++11 (IEEE_1666_CPLUSPLUS==201103L) o explicit sc_bitref_r<>::operator bool() const Restricts direct boolean conversion of bitvector element references to explicit boolean contexts (e.g. `if` expressions). Use the `to_bool()` function on earlier setups. In the future, further language features depending on modern C++ language constructs may be added. INSTALL: * SC_CPLUSPLUS - Override automatically detected C++ standard support This setting allows downgrading the assumed version of the underlying C++ standard on the current platform. By default, the latest supported version is chosen. Supported values are * SC_CPLUSPLUS=199701L (C++03, ISO/IEC 14882:1998, 14882:2003) * SC_CPLUSPLUS=201103L (C++11, ISO/IEC 14882:2011) * SC_CPLUSPLUS=201402L (C++14, ISO/IEC 14882:2014) Note: This symbol needs to be consistently defined in the library and any application linking against the built library. Especially the last note in the RELEASENOTES is relevant to your question: In order to reduce the complexity of all the different C++ language support differences across compiler versions, the LWG decided to at least enforce a consistent selection of the C++ baseline in the proof-of-concept implementation. Of course, other vendors may chose to allow more flexibility here, although sometimes even a consistent compiler version selection is mandated. With this decision, the implementation does not have to worry about binary compatibility across different (C++ standard dependent) feature sets in the future. As of today, the (currently internal) classes sc_type_index, sc_string_view differ depending on the platform's C++ standard support. Future extensions might change other classes as well. Not worrying about the ABI compatibility is a helpful simplification here. As described above, you can set -DSC_CPLUSPLUS=... consistently on the compiler command-line to build a single library build across several GCC versions. If supported by your platform/compiler, you can still use the different -std=c++XY flags (or their defaults) from the compilers, provided that they generate compatible code across the selected C++ standard version. Hope that clarifies the rationale behind the current implementation. Greetings from Duisburg, Philipp
  22. Did you include the required "extensions ctor" in your extension? template<unsigned DA_WIDTH> class scv_extensions<item_c<DA_WIDTH> > : public scv_extensions_base<item_c<DA_WIDTH> > { public: scv_extensions<sc_uint<DA_WIDTH> > addr; // ... SCV_EXTENSIONS_CTOR(item_c<DA_WIDTH>) { SCV_FIELD(addr); // ... } }; That said, (depending on your compiler) the current implementation of SCV_EXTENSIONS_CTOR is missing some "this->" qualifications in its body to cope with the different lookup rules for templated base classes. Hope that helps, Philipp
  23. Unfortunately, the fix for this issue didn't make it into the 2.3.2 public review release. But we have now a possible fix, which is under review for the final 2.3.2 release: In src/tlm_utils/multi_passthrough_target_socket.h, add the following lines before the loop in multi_passthrough_target_socket::end_of_elaboration(): // complete binding only if there has been a real bind bool unbound = (binders.size() == 1 && m_export_callback_created); // no call to get_base_interface has consumed the export - ignore if (unbound) return; Hope that helps, Philipp
  24. Philipp A Hartmann

    TLM payload extension declaration

    In general: Yes, this implementation is sufficient to implement a TLM2 extension. Still, there is a more reliable pattern to implement the copy_from and clone methods by using the copy constructor and assignment operator of your extension type (which you may need to implement in some cases anyway and will be provided for free in your particular example): class reg_extension : public tlm::tlm_extension<reg_extension> { public: tlm::tlm_extension_base* clone() const { return new reg_extension(*this); } // use copy constructor void copy_from(tlm::tlm_extension_base const & that ) { *this = static_cast<const reg_extension&>(that); } // use assignment operator // ... }; This pattern works very well for all Copyable and CopyAssignable classes without having to enumerate the members in clone and copy_from. Hope that helps, Philipp
  25. Exactly. Hope that helps, Philipp
×