Jump to content

Philipp A Hartmann

Members
  • Content Count

    487
  • Joined

  • Last visited

  • Days Won

    117

Everything posted by Philipp A Hartmann

  1. 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
  2. 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
  3. 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
  4. 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
  5. Exactly. Hope that helps, Philipp
  6. Hi S., The biggest issue in your code is that you set up the tracing before you initialize the "payload_data" pointer. Nothing good can come out of this. Secondly, sc_trace requires stable memory locations to trace, as it stores a pointer internally. So you can't easily reallocate the extension over and over again (or even later than the sc_trace call). Instead, I would suggest to reuse the extension across transactions and move it to a plain member in the class (changes added below): Hope that helps, Philipp
  7. Side note: You can't use virtual inheritance with SystemC modules. See the following thread for a related discussion: Your example doesn't require this, so it should be fine to simply drop the virtual keyword in the sc_module inheritance. Hope that helps, Philipp
  8. Philipp A Hartmann

    SystemC-2.3.1a clang build fail

    Maybe we can just reject "--enable-pthreads" on this platform explicitly. Generally speaking, you usually want to avoid pthreads, also on Linux, unless you have specific requirements. Greetings from Duisburg, Philipp
  9. Philipp A Hartmann

    SystemC-2.3.1a clang build fail

    Can you explain, why you try to use Pthreads on the Msys/MinGW platform? This environment doesn't come with a Pthreads library by default, you would need to install a separate one. And Pthreads will certainly be less efficient than the WinFiber-based process implementation. Thanks, Philipp
  10. Thanks for the reproducer, Sumit! This is indeed a regression compared to SystemC 2.3.0. I'll forward the issue to the SystemC Language Working Group. Greetings from Duisburg, Philipp
  11. The instance specific extension is tied to a specific accessor object (usually a member in a module, e.g. an interconnect). So each accessor can have its own extension object and is responsible for cleaning it up later. For regular TLM extensions, yes, there can only be one extension object of each type in a transaction payload.
  12. You can have a look at the "nb2b_adapter" test in the SystemC regression test suite, located at tests/tlm/nb2b_adapter/nb2b_adapter.cpp. In this example, you find the usage of an instance-specific extension for exactly that purpose: struct route_extension: tlm_utils::instance_specific_extension<route_extension> { int id; }; // ... virtual tlm::tlm_sync_enum nb_transport_fw( int id, tlm::tlm_generic_payload& trans, tlm::tlm_phase& phase, sc_time& delay ) { route_extension* ext = 0; if (phase == tlm::BEGIN_REQ) { ext = new route_extension; ext->id = id; // <-- store ID in the extension accessor(trans).set_extension(ext); } // ... virtual tlm::tlm_sync_enum nb_transport_bw( int id, tlm::tlm_generic_payload& trans, tlm::tlm_phase& phase, sc_time& delay ) { route_extension* ext = 0; accessor(trans).get_extension(ext); sc_assert(ext); tlm::tlm_sync_enum status; status = targ_socket[ ext->id ]->nb_transport_bw( trans, phase, delay ); // use ID from the extension Hope that helps, Philipp
  13. In line 33 of your producer.h, it seems you accidentally try to copy an interface (something derived from sc_interface). In order to give more detailed feedback, please share the code around the offending line. Hope that helps, Philipp
  14. Hi Sumit, even if the sockets are optional, you still need to bind at least one socket callback, right? Can you please check, that you actually do this? Greetings from Duisburg, Philipp
  15. On modern GCC versions (starting with 5.x), you the binary interface changed between C++03 and C++11 mode. You need to build your SystemC library with the same compiler (settings) to get the C++11 version of the functions. Hope that helps, Philipp
  16. Philipp A Hartmann

    SystemC 2.3:valgrind error

    Hi Jonas, for now, this is a known leak (as stacks from statically created processes are currently deliberately not deleted) and allocations from sc_core::sc_cor_pkg_*::create should be suppressed. (Dynamically created threads are not affected, so it is not a "real" leak). Greetings from Duisburg, Philipp
  17. Philipp A Hartmann

    Undefined behaviour in regression suite

    Hi Joshua, This could then indeed be a bug. I would expect that (sc_fix)(uint)-1 is a positive value? You say, that this is not the case? Thanks, Philipp
  18. Philipp A Hartmann

    Undefined behaviour in regression suite

    Hi Joshua, thanks for the report also from my side. I think, a better fix for the regression tests in question would be to use one of the explicit conversion functions in sc_fxval(_fast), see e.g. IEEE 1666-2011, 7.10.12.2: b[i] = (ushort)(b[i-1].to_ushort() * i * -1); The other question would be: Is the undefined behavior actually triggered? The quoted code looks like the sc_fxval values should indeed be positive as they have been assigned from a positive (ushort) value. The resulting double value then definitely holds a number that fits back into the unsigned short. Can you elaborate? Greetings from Duisburg, Philipp
  19. Philipp A Hartmann

    Usage of Sc_event_or_list

    Hi Jean-Claude, in SystemC, there is currently no way to identify whether an event has been triggered during/before the current evaluation phase in the simulation. See e.g. http://forums.accellera.org/topic/4925-/(and other threads) for earlier discussions. Btw: I find allEvents a confusing name for an sc_event_or_list. To me, wait(allEvents) sounds like waiting for all events to be triggered, whereas an or-list will trigger if any event in the list is notified. Greetings from Duisburg, Philipp
  20. I'm afraid, we need a more detailed analysis / debugging from someone, who has access to such a platform. Otherwise, we can just disable QuickThreads on Cygwin again and select Pthreads consistently instead. @Ralph: Can you try hunting this down in a debugger? Thanks, Philipp
  21. Hi Ralph, I agree, that the change in 2.3.1 is in violation of IEEE 1666-2011. And this needs to be fixed for sure. For 2.3.2, it's currently most likely that we just restore the original behavior. On the question of how to simplify the usage of sc_bitref in boolean contexts, we might also look into "explicit conversion to bool", see for example http://stackoverflow.com/questions/6242768/is-the-safe-bool-idiom-obsolete-in-c11. This needs further exploration and discussions in order to avoid escapes as in 2.3.1. This could be added to either sc_bitref<sc_bv_base> (sc_bitref<sc_lv_base>) (sc_logic) For the first option, I see the least risk of breaking the 1666-2011 compliance. The other two options could have more unwanted side-effects. The IEEE 1666-2011 sc_bit_ref template argument looks like an oversight to me. Will add this to the errata for review in IEEE later. Thanks and Greetings from Duisburg, Philipp
  22. Hi csr18, Thanks for reaching out on this topic. Allowing a conversion from sc_bitref to bool has been added intentionally to 2.3.1 to address the use case discussed at http://forums.accellera.org/topic/1392-/. With "this", Ralph is referring to the issue of now failing comparisons (and other operators) with character and some other literals, which now silently changed their meaning. This has been an unfortunate oversight in SystemC 2.3.1: sc_dt::sc_bv<1> bv = "1"; sc_assert( bv[0] ); // works now, great! sc_assert( bv[0] != '0' ); // broken! We're currently investigating options to restore the behavior required by 1666-2011. Have you seen other misbehaviors? Thanks and Greetings from Duisburg, Philipp
  23. Philipp A Hartmann

    Initialization of nested sc_vector< sc_vector< > >

    You need to add the preprocessor symbol SC_INCLUDE_DYNAMIC_PROCESSES to your build setup to enable sc_bind in SystemC, e.g. on the compilar command-line: -DSC_INCLUDE_DYNAMIC_PROCESSES. hth, Philipp
  24. Philipp A Hartmann

    Initialization of nested sc_vector< sc_vector< > >

    You can use a custom "creator" to initialize elements of a vector with custom constructor parameters - here the inner vector. Something like this (assuming you have lambda support available): auto element_creator = [](const char* nm, size_t) // optional, depending on the "real" value type { return new sca_module(nm); }; size_t inner_size = 42; // adjust for your needs, could also be a vector of sizes element.init( outer_size, [&](const char* nm, size_t) { return new sc_vector<sca_module>( nm, inner_size, element_creator ); } ); If you don't have lambdas in your environment, you need to put the functionality in a custom function, e.g. static sc_vector<sca_module>* element_vector_creator(size_t size, const char* name, size_t) { return new sc_vector<sca_module(name, size); } // using sc_bind to pass in the size - placeholders needed for actual call element.init( outer_size, sc_bind(element_vector_creator, inner_size, sc_unnamed::_1, sc_unnamed::_2) ); Hope that helps, Philipp
  25. Philipp A Hartmann

    tlm_fifo content safety

    Which version of SystemC/TLM are you using? I'm afraid, there is a known issue in the 2.3.1 circular_buffer implementation. When the fifo is destroyed while there are still elements in it, the loop over the "to-be-cleared" items does not start at the right index. Instead, you need the following change: circular_buffer<T>::clear() { for( int i=0; i < used(); i++ ) { - buf_clear( m_buf, i ); + buf_clear( m_buf, (m_ri + i) % m_size ); } // ... In 2.3, there was another indexing bug related to resize, see http://forums.accellera.org/topic/1443-/. Hope that helps, Philipp
×